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ABSTRACT 

This  thesis  describes  the  detailed  design  of  a 
distributed  operating  system  for  a  real-time,  microcomputer 
based  multiprocessor  system. 

Process  structuring  and  segmented  address  spaces 
comprise  the  central  concepts  around  which  this  system  is 
built.  The  system  particularly  supports  applications  where 
processing  is  partitioned  into  a  set  of  multiple  processes. 
One  such  area  is  that  of  digital  signal  processing  for  which 
this  system  has  been  specifically  developed. 

The   operating   system   is   hierarchically  structured  to 

logically  distribute  its  functions  in  each  process.  This  and 
loop-free  properties  of  the  design  allow  for  the  physical 
distribution  of  system  code  and  data  amongst  the 
microcomputers.  In  a  multiprocessor  configuration,  this 
physical  distribution  minimizes  system  bus  contention  and 
lays  the  foundation  for  dynamic  reconfiguration. 
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I.   INTRODUCTION 

A.   DISCUSSION 

The  topic  of  this  thesis  is  the  detailed  design  of  the 
kernel  of  a  real-time  microcomputer  based  multiprocessor 
operating-  system.  The  kernel  comprises  a  complete,  alteit 
primitive,  operating  system  providing  support  for  a  large 
number  of  asynchronous  processes. 

The  kernel  manages  all  physical  processor  resources 
thereby  providing  the  user  with  an  execution  environment 
relatively  free  from  concern  about  the  underlying  hardware 
configuration.  The  system  is  capable  of  performing  in  a 
real-time  environment  through  the  use  of  preemptive 
scheduling  to  ensure  expeditious  handling-  of  time-critical 
processing  requirements. 

Despite  the  rapidly  expanding  capabilities  of  modern 
microcomputer  systems,  they  still  prove  to  be  limited  by  the 
relatively  slow  execution  speeds  of  their  microprocessors. 
These  systems  generally  do  not  provide  the  power  and 
flexibility  required  to  address  complex  and  demanding 
applications.  One  such  area  is  that  of  real-time  digital 
image  processing.  This  is  a  particularly  demanding 
application  area  characterized  by  the  requirement  to  apply 
significant  processing  power  to  a  high  input  data  rate. 
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A  natural  ans'wer  to  the  inadequacies  of  the  lone 
microcomputer  is  to  provide  for  multiple  microcomputer 
systems.  Such  systems  could  provide  the  processing  power  to 
adequately  handle  applications  which  are  presently  addressed 
only  within  the  domain  of  minicomputers  and  mainframe 
systems.  However,  the  peneral  purpose  microcomputer 
operating  system  which  would  control  such  a  system  does  not 
exist  today.  Most  of  today's  microcomputer  operating  systens 
deal  only  with  uniprocessors  and,  in  fact,  could  not 
adequately  manage  multiple  processors. 

The  integration  of  large  numbers  of  relatively 
inexpensive  microcomputers  into  powerful  computer  systems 
has  "been  the  subject  of  intensive  research  in  universities 
and  industry  for  several  years.  As  a  result,  a  nurrber  of 
multiple  microcomputer  systems  such  as  Carnegie-Mellon 's  Cm* 
[ie]  have  been  "built  and  even  mere  such  as  the  varied 
architectures  of  Anderson  and  Jensen  [l]  have  "been 
sui??ested.  The  Cm*  is  an  ambitious  system  *ith  5£  processors 
and  a  complex,  custom  designed  and  built  bus  structure  [IS] . 
Most  of  the  proposed  systems  require  this  type  of 
specialized  hardware.  The  primary  thrust  of  this  thesis  is 
towards  a  general  control  structure  which  ran  be  applied  to 
hardware  systems  that  are  commercially  available  today  with 
only  very  minor  or  no  hardware  development.  Thus  no  serious 
attempt  is  made  to  consider  alternative  hardware 
architectures  as  a  tonic  in  this  research. 
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A  complete  high  level  operating  system  design  was 
provided  by  O'Connell  and  Richardson  [11]  in  their  family  of 
secure  multiprocessor  operating  systems.  This  thesis 
concerns  itself  with  the  detailing  of  one  member  of  their 
family,  a  modified  real-time  subset.  The  modification 
consists  of  the  inclusion  of  a  more  general  synchronization 
mechanism,  eventcounts  and  sequencers  described  by  Reed  and 
Kanodia  [13]  which  replace  the  more  traditional  Signal/Wait 
and  Block/Wakeup  used  in  the  original  design. 

The  system  supports  multiple  asynchronous  processes 
using  the  concept  of  two-level  traffic  control  to  accomplish 
processor  multiplexing  amongst  a  greater  number  of  eligible 
processes.  This  dual-level  processor  multiplexing  design 
allows  the  system  to  treat  the  two  primary  scheduling 
decisions,  viz.,  the  scheduling  of  processes  and  the 
management  of  processors  at  two  separate  levels  of 
abstraction. 

B.   STRUCTURE  OF  THE  THESIS 

Chapter  II  describes  the  overall  design  philosophy  of 
the  operating  system,  how  multiple  processes  are 
synchronized  and  how  their  multiplexing  on  a  smaller  set  of 
processors  is  accomplished.  Chapter  3  describes  the  hardware 
architecture  of  the  multiprocessor  system  in  terms  of  the 
particular  hardware  suite  chosen  for  this  system.  Chapter  IV 
discusses   the   details   of   the   kernel   design.   The  final 
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chapter  presents  conclusions  and  observations  that  resulted 
from  this  effort  and  suggestions  for  further  research.  Two 
appendices  are  also  provided,  an  explanation  of  programming 
methodology  for  this  system  and  a  detailed  description  of 
the    kernel    modules     in     their    present     form. 
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II.   FUNDAMENTAL  DESIGN  CONCEPTS 

A.   DESIGN  PHILOSOPHY 

Multiple  processor  systems  are  intrinsically  more 
complex  then  the  familiar  uniprocessor.  Their  complexity  has 
proven  to  be  the  major  barrier  to  realizing  the  full 
potential  of  the  inherent  parallelism  available  in  such  a 
system. 

One  of  the  most  important  components  of  any  computer 
system  is  the  operating  system.  The  operating  system  manages 
the  system's  resources.  Thus  system  performance  is 
critically  dependent  upon  its  effectiveness.  However, 
performance  is  not  just  raw  computational  speed,  but  is  in 
reality  the  sum-total  of  numerous  attributes.  Some  of  these 
system  attributes  such  as  ease  of  programming,  correct 
operation,  and  the  ability  to  address  diverse  applications 
are  as  important  as  speed  and  efficiency,  but  too  often  are 
overlooked.  Because  of  this  potentially  very  large  set  of 
requirements,  adequate  performance  can  only  be  assured  if 
the  behavior  of  the  system  is  well  understood  by  the 
designer.  Of  necessity,  this  imposes  a  strict  requirement 
for  simplicity. 

In  this  design,  the  requirement  for  simplicity  is 
satisfied  by  utilizing  a  model  based  on  the  notion  of 
multiple   asynchronous   processes  with  segmented   address 
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spaces.  This  is  the  central  unifying  concept  which  provides 
a  straightforward  view  of  both  static  and  dynamic  system 
behavior  [4].  The  principles  of  structured  system  design  are 
also  applied  to  logically  organize  the  operating  system  into 
a  hierarchically  structured  set  of  easily  understood  modules 
whose  interactions  are  clearly  specified  and  strictly 
enforced . 

The  result  is  a  modular,  layered  operating  sytem  which 
is  both  smaller  and  easier  to  analyze.  This,  in  turn  makes 
it  easier  to  ensure  correct  operation  and  provides  better 
opportunity  for  improving  performance  through  tuning. 
Certain  other  benefits  accrue  from  simplif icaton  as  well. 
Because  the  sytem  is  smaller,  less  memory  is  used  for 
operating  system  code  and  less  processor  time  is  spent  in 
its  execution. 

B.   SEQUENTIAL  PROCESSES 

1 .   Definition  of  a  Process 

The  concept  of  a  process  has  proven  to  be  a 
fundamental  and  powerful  one  in  the  organization  cf  computer 
systems.  The  rather  abstract  idea  of  a  process  has  been 
defined  in  numerous  ways,  but  perhaps  the  simplest  is 
offered  by  J.  Saltzer  as: 

"...basically  a  program  in  execution  on  a  processor."  Fl7] 

In  considering   the   above   definition,   it   becomes 

apparent    that    there   are   two   elements   which   together 
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completely  characterize  a  given  process.  They  are  1)  the 
program,  consisting  of  any  sequentially  executed  machine 
instructions  and  data  which  can  he  associated  with  the 
program  (usually  termed  the  process'  address  space)  and,  2) 
the  execution  state  of  the  process  which  is  characterized  by 
the  contents  of  certain  processor  registers. 
2.   The  Process  Address  Space 

The  address  space,  simplistically ,  provides  for  the 
encapsulation  of  a  process  such  that  it  has  no  knowledge  of 
any  other  process  and  no  other  process  has  knowledge  of  it. 
This  eliminates  the  possibility  of  inter-process 
interference  simply  "because  processes  are  unahle  to  "escape" 
the  confines  of  their  defined  address  spaces. 

However,  this  is  rather  restrictive  in  that 
processes  which  are  totally  ignorant  of  each  other  have  no 
hope  of  co-operating  towards  the  accomplishment  of  some 
greater  roal.  In  order  to  mediate  this  constraint,  one 
desires  to  allow  some  restricted  (controlled)  form  of 
address  space  overlap  (viz.,  sharing)  such  that  co-operation 
is  allowed  while  still  retaining  the  benefits  of  protection 
offered  by  isolation.  Snaring  requires  some  way  cf 
distinguishing  the  shared  portions  of  the  address  space. 
This  is  greatly  facilitated  by  introducing  the  notion  of 
memory  segmentation. 


a.  Virtual  Memory  and  Segmentation 

Virtual  memory  is  used  to  implement  the  concept 
of  a  per  process  address  space.  In  Multics  [2],  each  process 
is  provided  with  its  own  virtual  memory  for  an  address 
space.  These  virtual  memories  are  completely  independent  of 
one  another. 

A  virtual  memory  consists  of  a  set  of  segments. 
Segments  are  distinct  variable  size  memory  objects  which 
contain  information.  Associated  with  a  segment  is  a  set  of 
logical  attributes  used  to  uniquely  identify  the  segment  and 
to  control  access  to  it. 

In  specifying  the  set  of  segments  that  comprise 
a  virtual  memory,  one  may  include  segments  that  are  part  of 
other  virtual  memories  as  well.  Thus  segments  can  he  shared 
in   a   controlled  manner   to   provide    for   inter-process 

communication  and  co-operation. 

By  using  segmentation  to  provide  a  virtual 
memory  environment,  the  user  is  presented  with  a 
configuration  independent  system  in  that  ne  "sees"  a  process 
address  space  that  he  can  consider  his  own  and  is  not 
dependent  on  the  assignment  of  physical  addresses. 

b.  Addressing  in  a  Segmented  System 

Addressing  in  a  segmented  memory  system  is 
two-dimensional.  That  is,  a  complete  address  consists  of  two 
parts.  The  first  is  the  segment  number.  This  identifies  the 
particular  segment  of  interest.  One  attribute  of  the  segment 
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is  the  physical  address  of  the  segment's  base.  Thus  the 
segment  can  be  located  anywhere  in  physical  memory  "by 
changing  the  base  address.  The  second  dimension  of  the 
address  is  an  offset  relative  to  the  segment's  base  (the 
beginning  of  the  segment).  This  serves  to  access  specific 
locations  within  the  segment. 

C.   INTER -PRO CESS  SYNCHRONIZATION  AND  COMMUNICATION 

Utilizing  the  parallelism  afforded  by  multiple 
processors  requires  a  mechanism  for  inter-process 
communication  and  synchronization.  It  is  used  for 
controlling  the  execution  of  processes  and  coordinating  the 
sharing  of  data. 

The  most  widely  used  synchronization  primitives  are 
Dijkstra's  semaphores  [3]  or  Saltzer's  Block  and  Wakeup  [17] 
which  were  used  in  O'Connell  ard  Richardson's  original 
design  [11].  However,  the  design  decision  was  made  to  use  a 
different  mechanism  which  addresses  the  questions  of 
confinement  in  a  secure  system.  This  is  the  synchronization 
mechanism  based  on  the  eventcounts  and  sequencers  of  Peed 
and  Kanodia  [13] . 
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D.   PROCESSOR  MULTIPLEXING 

1.  refinition  of  Processor  Multiplexing 

Processor  multiplexing  is  a  technique  for  sharing 
scarce  processor  resources  among  an  arbitrarily  large  number 
of  processes.  It  is  accomplished  "by  simulating  the  existence 
of  a  larger  number  of  virtual  processors.  This  technique  is 
widely  used  in  conventional  uniprocessor  systems  where  it  is 
commonly  called  multiprogramming.  It  seeks  tc  maximize  the 
use  of  the  available  hardware  by  automating  control  of 
process  loading  and  execution.  It  also  greatly  increases  the 
flexibility  of  a  system  allowing  it  to  be  effective  in  more 
complex  and  demanding  applications. 

J.  H.  Saltzer  [17]  presented  one  of  the  fundamental 
works  on  the  subject  of  processor  multiplexing.  His  thesis 
provides  an  excellent  treatise  of  the  salient  issues. 

2.  Processor  Visualization 

In  order  to  effect  processor  multiplexing,  the 
physical  processor  resources  (those  hardware  devices  that 
execute  machine  instructions)  are  virtualized  by  creating 
abstract  processors  called  virtual  processors. 

a.  Virtual  Processors 

Each  physical  processor  posseses  some  internal 
memory  (registers)  whose  contents  describe  the  processor's 
state.  As  part  of  the  processor  state,  there  is  a 
specification  of  the  accessible  address  space- which  contains 
the  instructions  and  data  used  by  the  processor. 
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Virtual  processors  are  simulations  of 
processors.  They  can  "be  viewed  in  essentially  the  same  way 
as  physical  processors  in  that  they  execute  the  same 
instructions.  However,  the  instruction  set  cf  a  virtual 
processor  has  "been  expanded  to  include  some  instructions 
which  the  physical  processors  do  not  directly  have.  These 
include  "instructions"  to  "load"  a  process,  certain 
synchronication  primitives,  system  service  calls,  etc. 

Virtual  processors  exist  only  as  abstract 
processors  represented  by  a  data  structure.  They  are  used  as 
the  vehicle  for  the  control  and  manipulation  of  processor 
resources . 

3.   Two-Level  Processor  Multiplexing 

In  this  design,  there  are  two  levels  of  processor 
multiplexing.  This  design  arose  from  the  existence  of 
multiple  physical  processors.  Each  of  the  levels  address  a 
distinct  requirement.  One  level  supports  virtual  processor 
management,  that  is,  the  prevision  of  inter-process 
synchronization.  The  other  supports  the  management  of 
physical  resources  "by  the  operating  system. 

This  divides  the  requirements  for  multiplexing 
mechanisms  into  two  parts.  One  of  these  addresses 
multiplexing  virtual  processors  among  processes  and  the 
other  multiplexing  physical  processors  among  virtual 
processors . 
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a.   The  Traffic  Controller 

The  Traffic  Controller  represents  the  upper  level 
of  processor  multiplexing  (termed  level  2)  and  provides  the 
mechanism  for  multiplexing  virtual  processors  among 
processes.  Thus  it  is  responsible  for  inter-process 
synchronization. 

As  an  example,  consider  that  a  process,  called  A, 
will  wish  to  synchronize  its  actions  with  another  process, 
called  B,  such  that  process  B  will  have  to  complete  some 
task  "before  A  can  continue  execution.  Thus  A  will  execute  to 
the  point  where  it  cannot  proceed  further  and  wishes  to 
signal  process  E.  When  process  B  has  finished  its  task,  it 
must  notify  process  A  of  its  completion  so  that  process  A 
may  then  proceed. 

This  inter-process  synchronization  is  handled  at 
the  level  of  the  Traffic  Controller.  When  process  A 
discovered  that  it  could  not  proceed  further,  it  "gave  away" 
its  virtual  processor  to  some  process  that  could  run.  The 
Traffic  Controller  suspended  the  execution  of  process  A  and 
a  new  process  was  hound  to  the  virtual  processor.  In  the 
same  way,  when  3  completes,  viz.,  it  has  no  more  work  to 
perform,  it  will  also  give  its  virtual  processor  away. 

b.   The  Inner  Traffic  Controller 

The  Inner  Traffic  Controller  comprises  the 
lower  level  of  processor  multiplexing  (level  1)  and  provides 
the  second  set  of  multiplexing  functions.  It  multiplexes  the 
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physical  processor  amon^  one  or  more  virtual  processors. 
While  the  virtual  processors  have  identical  capabilities , 
the  physical  processors  may  differ  in  their  capabilities , 
viz.,  they  may  have  different  attached  I/C  devices, 
different  local  memory  sizes,  etc.  The  Inner  Traffic 
Controller  must  manage  the  physical  resources  in  such  a  way 
that  the  user  is  unaware  of  these  differences.  In 
particular,  the  system's  interrupt  system  is  managed  by  the 
Inner  Traffic  Controller. 

If  a  user  process  calls  upon  some  system  service, 
such  as  disk  I/O  or  I/O  for  a  real-time  sensor,  it  must  wait 
for  that  service  to  be  completed  before  it  can  proceed.  The 
performance  of  a  system  service  is  considered  to  be  part  of 
the  requesting  processes.  However,  it  may  actually  be 
supported  by  another  virtual  processor.  To  control  this 
interaction  the  Inner  Traffic  Controller  orcvides  the 
required  inter-virtual  processor  synchronization  mechanism. 
In  particular,  a  physical  system  interrupt  is  directly 
transformed  into  a  synchronization  signal  to  a  waiting 
virtual  processor.  This  structure  is  particularly  important 
for  the  support  of  real-time  processing. 
4.  Processor  Multiplexing  Strategy 
a.   Process  State  Transitions 

Figure  1  illustrates  the  state  transitions  of  a 
set  of  processes  as  a  virtual  processor  is  multiplexed  amon^ 
them.  Some  eligible  process   (one  which   is   in   the   ready 
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state)  is  scheduled  to  run  and  is  bound  to  the  virtual 
processor.  At  this  time,  the  process  makes  the  transition  to 
the  running  state.  As  far  as  the  process  is  concerned,  once 
it  enters  the  running  state,  it  is  executing. 

At  some  point  in  its  execution,  the  process  may- 
desire  to  block  itself  or  signal  another  process.  If  it 
"blocks  itself  (enters  the  blocked  state),  it  will  give  up 
the  virtual  processor  to  which  it  is  presently  bound  and 
will  be  out  of  contention  for  processor  resources.  It  will 
remain  in  the  blocked  state  until  some  other  process  signals 
it  (thus  making  the  transition  back  to  the  ready  stateK  If 
the  process  signals  other  processes,  it  will  transition  from 
the  running  state  back  to  the  ready  state  from  which  it  may 
be  scheduled  to  run  again.  In  doing  so,  it  allows  the 
Traffic  Controller  to  possibly  give  the  virtual  processor  to 
some  higher  priority  process  which  may  be  ready  to  run. 
b.   Virtual  Processor  State  Transitions 

Figure  2  illustrates  the  state  transitions  made 
by  virtual  processors  as  a  physical  processor  is 
multiplexed.  This  diagram  is  very  similar  to  that  of  Figure 
1.  However,  these  transitions  are  not  directly  observeable 
by  processes  (except  as  differences  in  execution  times)  as 
virtual  processor  state  transitions  result  from  the 
management  of  physical  resources  by  the  operating  system. 

In  Figure  2,  it  can  be  seen  that  a  running 
virtual  processor  can  transition  to  the  waiting  state  or  the 
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ready  state.  The  transition  to  the  waiting  state  occurs  when 
a  virtual  processor  must  wait  for  completion  of  some  system 
service  (analogous  to  the  blocking  of  process  A  in  the 
example  siven  in  paragraph  a).  While  in  the  waiting  state, 
the  virtual  processor  is  out  of  contention  for  processor 
resources  until  another  virtual  processor  signals  it  to 
continue.  While  in  the  ready  state,  the  virtual  processor  is 
in  contention  for  processor  resources  and  so  may  te 
scheduled    to    run     on    the    physical     processor. 
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III.   MULTIPROCESSOR  ARCHITECTURE 

A.   HARDWARE  REQUIREMENTS 

One  of  the  principal  design  *?oals  of  the  system  design 
was  to  provide  for  configuration  independence.  Therefore, 
the  operating  system  imposes  "but  a  few  constraints  on  the 
hardware  that  are  noted  here. 

1 .  Shared  Global  Memory 

The  operating  system  maintains  system-wide  control 
data  accessible  to  each  of  the  processors  via  shared 
segments.  The  communication  path  utilized  for  sharing  this 
data  is  shared  memory.  Thus  some  shared  memory  must  be  made 
available  to  each  microcomputer  in  such  a  way  as  to  allow 
independent  access  at  the  level  of  single  memory  references. 

2.  Multiprocessor  Synchronization   Support 

There  must  exist  some  hardware-supported 
multiprocessor  synchronization  primitive.  This  can  be  any 
form  of  an  indivisible  read-alter-rewrite  memory  reference. 
This  capability  is  required  to  implement  global  locks  on 
shared  data  to  prevent  race  conditions  as  the  physical 
processors  attempt  to  asynchronously  manipulate  shared  data. 

3.  Inter -Processor  Communication 

Some  method  of  communication  between  physical 
processors  must  be  provided.  This  is  satisfied  by  an  ability 
to  generate  interrupts  between  the  physical  processors.  This 
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capability  is  required  for  the  implementation  of  preemptive 
scheduling . 

B.   HARDWARE  CONFIGURATION 

1 .  System  Configuration 

The  hardware  sub-system  is  configured  as  a 
multiprocessor  [l] .  The  system  consists  of  a  number  of 
single  hoard  microcomputers  and  a  global  memory  module 
connected  "by  a   single  snared  "bus.  The  system  differs  from 

* 

conventional  multiprocessors  in  that  each  of  the 
microcomputers  possesses  its  own  local  memory.  The  global 
memory  module  is  connected  directly  to  the  system  bus  and  is 
the  only  physical  memory  resource  which  is  shared  by  all   of 

the   processors.   The   general   configuration   is   shown 

> 

schematically  in  Figure  3. 

2.  Specific  Hardware  Employed 

The  particular  hardware  selected  for  this 
implementation  is  based  on  the  INTEL  66/12A  single  board 
microcomputer  [6].  This  microcomputer  utilizes  the  INTEL 
82&6i  a  16-bit  general-purpose  microprocessor  capable  of 
directly  addressing  a  total  of  1  mega-byte  of  physical 
memory. 

a.   The  8086  Microprocessor 

The  8£66  does  not  support  the  notion  of  explicit 
segmentation.  In  the  8086,  addressing  is  segment-like  in 
that  base  and  offset  addressing  is   used.   The  offsets   are 
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formed  relative  to  one  of  the  four  segment  "base  registers  of 
the  8086:  1)  the  Code  Segment  Register,  used  for  addressing 
a  pure  segment  containing  executable  code,  2)  the  Tata 
Segment  Register,  used  for  process  local  data,  3)  the  Stack 
Segment  Register,  used  for  the  per  process  stacks,  and  4) 
and  the  Extra  Segment  Register,  typically  used  for  external 
or  shared  data. 

In  the  £086,  a  segment  can  range  anywhere  up  to 
64  kilo-bytes  in  length.  Segments  can  "be  placed  anywhere 
within  the  1  me^a-byte  address  space  of  the  £££5  as  long  as 
the  segment  "base  is  placed  on  an  even  hexadecimal  memory 
address.  Segment  access  and  hounds  checking  are  not 
supported.  Although  there  is  no  general  segmentation 
hardware,  this  design  effects  a  segmented  address  space 
through  a  combination  of  operating  system  support  and  system 
initialization  conventions  described  in  a  companion  thesis 
by  Ross  [16] . 

b.  The  86/12A  Single  Board  Microcomputer 
The  B6/12P>  is  a  complete  computer  capable  of 
stand-alone  operation  used  as  the  basic  processing  node  of 
the  multiprocessor.  It  is  a  commercial  product  which 
satisfies  the  three  basic  hardware  requirements  for  this 
operating  system.  First,  possessing  a  system  bus  interface, 
each  microcomputer  is  capable  of  independently  accessing-  a 
global  shared  memory  via  the  system  bus.  Secondly,  the  8£36 
CrU   supports  multiprocessor  synchronizaton  directly  with  an 
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indivisible  test-and-set  semaphore  instruction  performed 
under  "bus  lock.  Lock  semaphores  reside  in  the  shared  global 
memory  since  the  system  bus  must  be  locked  to  ensure  that 
this  instruction  operates  correctly.  Thirdly,  preempt 
interrupts  can  be  generated  by  using  the  parallel  I/O  ports 
provided  on  each  microcomputer.  This  requires  connecting  the 
microcomputer's  parallel  I/O  ports  to  the  system  interrupt 
structure . 

c.   Freempt  Interrupt  Fardware  Connection 

As  with  most  microprocessors,  the  8086  itself 
does  not  possess  the  capability  to  directly  generate 
interrupts  destined  for  other  devices  (the  devices  of 
interest  here  are  other  processors).  The  system  interrupt 
lines  are  accessible  through  a  jumper  matrix  [6]  located  on 
the  microcomputers.  The  parallel  I/O  port  output  of  each 
ISBC  85/12A  is  connected  to  this  interrupt  jumper  matrix. 
Preempt  interrupts  are  then  generated  simply  by  outputting  a 
single  word  through  the  parallel  port  onto  the  system 
interrupt  lines.  The  connection  is  shown  in  Figure  4. 

Note  that  only  a  single  interrupt  line  is 
actually  required  to  implement  system-wide  preempt 
interrupts.  In  this  implementation,  four  lines  are  used. 
This  provides  four  unique  interrupt  lines.  If  more  than  four 
processors  are  used  in  the  system,  then  these  lines  are 
multiplexed  (viz.,  several  processors  share  an  interrupt 
line) . 
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d.   The  System  Bus 

The  Intel  MUITI3US  [6]  is  utilized  as  the  system 
bus.  It  is  a  widely  used  commercial  product  with  a  published 
set  of  standards.  This  bus  is  specifically  designed  to 
support  multiple  processors  and  is  fully  compatible  with  the 
microcomputers  used.  It  is  utilized  without  modification. 

C.   EAR I WARE  ASSESSMENT 

The  commercially  available  66/12A  single  board 
microcomputer  was  chosen  because  it  was  specifically 
designed  to  provide  support  for  multiple  processor  systems. 
In  using  the  operating  system  described  in  the  next  chapter 
to  manage  the  microcomputer's  physical  resources,  this 
microcomputer  is  entirely  suitable  for  use  as  a  basic 
processing  node  of  an   effective  multiprocessor   system. 
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IV.   DETAILED  SYSTEM  DESIGN 

A.   STRUCTURE  OF  TEE  OPERATING  SYSTEM 

This  operating  system  provides  a  mul ti programmed 
multiprocessor  system  with  segmented  process  address  spaces 
using  the  hardware  described  in  Chapter  III.  The  operating 
system  is  structured  as  a  hierarchy  of  three  levels  [11] ,  as 
follows : 

level  3:   Supervisor 

level  2:   Traffic  Controller 

level  1:   Inner  Traffic  Controller 

The  Inner  Traffic  Controller  (Level  1)  forms  the 
"bottom  level  of  the  hierarchy.  It  is  "closest"  to  the 
hardware  and  encompasses  the  major  machine-dependent  aspects 
of  the  system.  The  Inner  Traffic  Controller  multiplexes  the 
physical  processor  amongst  a  pool  of  more  numerous  virtual 
processors . 

Residing  at  the  next  level  (level  2)  is  the  Traffic 
Controller,  which  is  responsible  for  multiplexing  virtual 
processors  among  a  larger  number  of  user  processes  competing 
for  resources.  The  user-accessible  inter-process 
communication  and  synchronization  primitives  (Advance,  Await 
and  Ticket^  provided  at  this  level  allow  the  user  to  easily 
address  complex  system-wide  inter-process  synchronization 
requi  rements . 
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The  Supervisor  resides  at  the  topmost  level  (level 
3).  The  Supervisor's  purpose  is  to  provide  common  services 
for  user  processes.  In  this  implementation,  it  only  provides 
a  simple  higher  order  language  interface  to  the  kernel  by 
having  a  single  entry  point  into  the  kernel. 

3.   DISTRIBUTING  TEE  OPERATING  SYSTEM 

One  of  the  primary  concerns  in  any  multiple  computer 
system  is  the  issue  of  performance.  In  this  type  of  system, 
a  multiprocessor  with  a  single  shared  system  "bus,  the  most 
glaring  potential  bottleneck  is  the  system  "bus.  It  then 
becomes  highly  desirable  to  minimize  accesses  to  this 
resource  that  must  be  shared  by  all  of  the  microcomputers. 

In  terms  of  the  design,  the  described  system  is  a 
distributed  operating  system  patterned  after  Multics  [12]. 
In  particular,  the  segments  of  the  operating  system  kernel 
are  distributed  as  part  of  the  address  space  of  each 
process.  In  terms  of  the  implementation  of  this  system,  the 
performance  issue  is  addressed  by  physically  distributing 
copies  of  the  kernel  in  the  local  memories  of  each  of  the 
microcomputers.  This  allows  high-speed  access  to  kernel 
functiors  without  necessitating  use  of  the  system  bus  for 
code  fetches. 

Thus  each  computing  node  can  be  regarded  as 
semi-autonomous  in  that  each  of  the  processors  schedule 
themselves  but  are  still  centrally  controlled  by  the  set   of 
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system-wide  data  tables.  There  is  no  concept  of  a 
master-slave  relationship  anion?  individual  microcomputers, 
nor  are  individual  kernel  functions  divided  up  among  them  as 
is  more  often  done.  Rather  the  entire  kernel  is  distributed. 

C.  REAI-TIME  PROCESSING 

Real-time  processing  involves  the  performance  of 
time-critical  processing  often  related  to  the  control  of 
external  devices.  This  application  requires  that  some 
mechanism  be  employed  to  ensure  that  time-critical 
processing  is  ffiven  immediate  attention. 

The  hardware-supported  process  preemption  mechanism 
employed  in  the  system  provides  the  rapid  response  required 
for  real-time  processing.  The  priority-driven  preemptive 
scheduling  technique  used  provides  for  expeditious  handling 
of  processes  which  perform  time-critical  functions.  These 
processes  are  assigned  high  priorities  so  that  the  system 
will  preempt  other  processes  of  lower  priority  that  may  be 
running.  Thus  when  one  of  these  high-priority  processes  is 
signalled,  it  can  be  immediately  scheduled  and  gain  control 
of  processor  resources. 

D.  PROCESS  ADDRESS  SPACES 

The  address  space  of  a  process  is  a  set  of  FL/M-66 
segments:    procedures    (code),    local   variables   (data), 
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external  data  (shared  data),  and  stack  [12,13].  Physical 
memory  is  allocated  to  the  segments  of  a  process  in  such  a 
way  as  to  limit  system  "bus  contention,  as  discussed  by  F.oss 
[16].  In  this  system,  the  stack  is  a  key  element  in  the 
management  of  processes. 

1.  The  PL/M-S6  Stack 

Intel's  high  order  language  PL/M-S6  [5,  1£]  utilizes 
stack  segments  to  implement  per  process  stacks.  Addressing 
of  stacks  is  accomplished  by  using  three  of  the  B£S6's 
registers  as  shown  in  Figure  5.  The  Stack  Segment  (SS) 
Register  contains  the  base  location  of  the  stack  segment  in 
memory.  The  Stack  Pointer  (S?)  Register  addresses  the 
current  top  of  the  stack  as  ar  offset  from  the  tase  of  the 
stack  segment,  (the  value  in  the  SS  Register).  The  Ease 
Pointer  (BF)  Register  also  holds  an  offset  from  the  SS 
Register  and  is  used  to  establish  procedure  activation 
records  [7,  8,  9] . 

2.  The  S,tack  as  the  Address  Space  Pescriptor 

In  this  system,  the  per  process  stacks  are  used  to 
maintain  process  state  information.  This  includes  the 
current  execution  point  (when  the  process  is  not  actually 
running),  the  type  of  return  from  the  kernel  required  for 
the  process  (normal  or  interrupts  and  the  locations  of  the 
code  and  data  segments.  This  allows  the  system  to  swap  in  a 
new  address  space  (viz.,  do  a  context  switch)  by  changing 
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the  value  in  the  SS  Register,  which  is  thus  used  in  a  manner 
somewhat  analogous  to  the  Multics  Descriptor  Ease  Register 
[12]. 

Figure  6  shows  how  this  information  is  stored  in  the 
stack  while  a  process  is  not  actually  running  on  a  physical 
processor.  The  Base  Pointer,  Stack  Pointer  and  Return  Type 
Indicator  are  stored  in  reserved  locations  at  the  very 
beginning  of  the  stack  segment. 

In  order  to  identify  the  stack  segment,  and  thus 
access  the  address  space  of  a  process,  the  stack  segment 
"base  address  is  used  in  a  dual  role.  First,  a  unique  "base 
address  is  assigned  to  the  stack  of  each  process  which 
provides  a  unique  segment  for  each  stack.  This  "base  address 
is  used  for  addressing  locations  within  the  stack.  Secondly, 
the  "base  address  serves  as  a  descriptor  for  the  address 
space  of  each  process.  Thus  the  binding  of  a  processor  is 
changed  from  one  process  to  another  "merely"  "by  chan^in,?  the 
base  address,  viz.,  changing  the  value  in  the  Stack  Segment 
(SS)  Register. 

E.   SYSTEM  PROCESSES 

System  processes  make  up  the  non-di stributed  kernel. 
Non-distributed  refers  to  the  fact  that  these  processes  are 
not  distributed  as  part  of  each  process'  address  space. 
Rather  they  represent  various  system  services.  System 
processes  are  used  for  the  management  of  hardware  resources 
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and   execute   asynchronously  with  respect  to  user  processes. 
In  this  design,  all  system  processes  are   permanently   bound 
to  dedicated  virtual  processors. 
1 .   The  Idle  Virtual  Processor 

The  idle  virtual  processor  provides  the  physical 
processor  with  a  consistent  state  when  no  other  virtual 
processor  is  ready  to  he  run.  The  idle  virtual  processor 
assures  that  physical  processors  always  have  some  valid 
process  address  space  to  execute  in,  although  in  this  case 
it  is  only  an  idle  process  that  performs  no  useful  work. 

This  is  assumed  by  creating  for  each  physical 
processor  a  dedicated  idle  virtual  processor.  The  idle 
virtual  processors  act  as  "default"  that  will  only  he  run 
when  no  other  runnable  virtual  processors  are  found. 

F.   SYNCHRONIZATION 

Synchronization  is  required  at  two  levels  in  this 
system:  between  processes  (at  the  Traffic  Controller  level) 
and  between  virtual  processors  (at  the  Inner  Traffic 
Controller  level).  Both  levels  use  the  eventcount  and 
sequencer  mechanisms  [13]  described  below. 

1 .   Sventcounts 

Eventcounts  are  used  in  this  system  to  allow 
processes  to  arbitrate  access  to  shared  resources. 
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An  eventcount  is  defined  by  Reed  to  be: 

"an  object  in  the  system  that  represents  a  class  of  events 
that  will  eventually  occur."  [14] 
Each  eventcount  represents  a  distinct  class  of  events.  An 
eventcount  is  associated  with  seme  type  of  event  of 
interest,  e.g.,  occurrence  of  a  real-time  interrupt*  a 
buffer  becoming  full,  a  data  segment  being  read  or  written 
into,  etc.  Eventcounts  are  implemented  as  sets  of  positive 
integers  from  1  to  infinity  (the  limit  is  actually  65,536 
using  Pl/M-86  "word"  variables  which  is  "adequate"  for  the 
applications  anticipated)  and  are  used  to  keep  track  of  the 
total  number  of  such  events  that  have  occurred. 

Three  operations  are  defined  on  eventcounts.  The 
value  of  an  eventcount  may  be  obtained  by  the  READ 
operation.  This  returns  the  present  value  of  the  eventcount 
as  a  positive  integer  k.  From  this  value,  one  may  infer  that 
events  0  to  k  have  already  occurred. 

The  AWAIT  operation  allows  a  process  to  suspend  its 
own  execution  (enter  the  blocked  state)  until  a  specified 
event  has  occurred,  viz.,  the  eventcount  reaches  the  value 
specified.  The  effect  is  the  same  as  the  conventional  Block 
operation  or  Dijkstra's  "p"  operator. 

An  ADVANCE  operation  is  performed  by  a  process  when 
an  event  has  occurred.  It  increments  the  value  of  the 
eventcount  by  one  to  reflect  the  occurrence  of  the  event. 
This  has  the  effect  of  signalling  the  event's  occurrence   to 
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other  processes  which  were  waiting  for  it  "by  virtue  of 
having  previously  performed  an  AWAIT  operation.  The  effect 
of  an  ADVANCE  operation  is  essentially  the  same  as  a  Vakeup 
operation  or  Dijkstra's  "v"  operator. 

The  eventcount  signalling  mechanism  has  an  automatic 
"broadcast  effect  which  offers  an  advantage  in  parallel 
processing.  This  "broadcast  capability  allows  the 
simultaneous  signalling  of  several  processes  which  otherwise 
would  would  have  to  "be  signalled  sequentially. 
2.   Sequencers 

There  are  many  situations  where  accesses  to  shared 
resources  must  he  totally  ordered.  Eventcounts  alone  are  not 
sufficient  to  accomplish  this.  To  provide  the  capability  for 
mutual  exclusion,  another  type  of  object  called  a  sequencer 
[13]  is  employed.  A  sequencer  is  implemented  as  a  positive 
integer  ranging  in  value  from  2  to  infinity  (as  with 
eventcounts,  the  limit  is  65,533).  Fowever,  a  sequencer  is 
used  to  provide  total  order  to  the  occurrence  of  events. 
Initially  a  sequencer  has  a  value  of  0.  The  value  increases 
by  one  each  time  a  TICKET  operation  is  performed  en  it. 
TICKET  is  the  only  operation  defined  on  a  sequencer.  TICKET 
returns  a  unique  mono tonically  increasing  value  with  each 
call.  Thus,  a  set  of  events  can  be  totally  ordered  by  the 
TICKET  operation. 
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3.   Inter-Process  Synchronization 

Access  to  shared  resources  is  easily  controlled  by 
using  eventcounts  and  sequencers  in  concert,  as  shown  in  the 
following  "producer/consumer"  example  [13] . 

Consider  that  some  hypothetical  consumer  process 
called  Printer  uses  a  single  input  buffer  in  which  it  finds 
information  to  be  processed  (output  to  the  printer).  There 
are  also  an  unknown  number  of  producer  processes  called 
PPOn,  PF0D2,  etc.,  which  have  information  that  they  want 
Printer  to  output  for  them.  Obviously,  with  a  single  buffer, 
only  one  of  the  processes  can  use  the  buffer  at  any  one 
time.  The  solution  uses  one  sequencer  and  two  eventcounts  to 
properly  mediate  access  to  the  buffer  using  mutual 
exclusion. 

The  sequencer  Turn  is  used  by  the  producer  processes 
to  synchronize  their  use  of  the  input  buffer.  The 
eventcounts  Full  and  Empty  are  used  to  synchronize  with 
Printer.  Each  of  the  producer  processes  will  execute  the 
program  shown  below. 

PP0D1,  PR0D2,  etc.    /*  Producer  programs       */ 

do; 

T  =  TICKET(TURN);  /*  Get  a  "ticket"  (turn)    */ 

/*  for  the  buffer  */ 

AWAIT (EMPTY, T)J    /*  Wait  for  buffer  ready    */ 

/*  Write  into  the  buffer   */ 

ADVANCE (FULL);     /*  Signal  Frinter  that      */ 

/*  there  is  work  to  do     */ 

end;  /*  do  */ 
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Each  of  the  producer  processes   first   performs   a 

TICKET   operation  on  the  sequencer  Turn  to  obtain  a  "ticket" 

for  the  buffer.  Each  time  TICKET  is  called,  the   variable   T 

of  the  calling  producer  process  will  receive  a  unique  value. 

This   value   is   then   used  by   the   producer  process  as  an 

argument  for  the  call  to  AWAIT.  It  is  the   event   (value   of 

the  eventcount  EMPTY)  for  which  the  process  will  wait.  When 

that  event  does  occur  (the  value  of  Empty,  which  is  advanced 

by  Printer,  reaches  the  value   specified   in   the   call   to 

AWAIT)  the  process  will  be  unblocked  and  may  then  proceed  to 

use   the   buffer.   When   it  has   finished,  the  process  will 

perform  an  ADVANCE  operation  on   the   eventcount  Full   to 

signal   Printer   that   there   is   information   in   the  irput 

buffer.  Since  each  producer  process  uses  the  same  sequencer, 

only  one  of  them  at  a  time  will  access  the  buffer. 

The   consumer  process   Printer   is   programmed   as 

follows . 

PRINTER  /#  Consumer  program  */ 

DO  I  =  1  TO  65536;    /*  Essentially  forever       */ 
AWAIT(FULI,I);     /*  Wait  for  a  message  to  be   */ 

/*  deposited  in  the  buffer   */ 

/*  Perform  output  function   */ 

• 

ADVANCE(EMPTT) J    /*  Notify  waiting  processes  */ 

/*  that  the  buffer  is  now  */ 

/*  available  */ 
END;  /*  DO  */ 

The  Printer  process  synchronizes  on  the  eventcount 

Full  (it  waits  until   Full   is   advanced  by   some   producer 

process   that   has  finished  using  the  buffer).  After  Printer 
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finishes  with  the  "buffer,  it  performs  an  ADVANCE  operation 
on  the  eventcount  Empty.  This  notifies  the  producer  process 
that  is  "next  in  line"  that  the  "buffer  is  now  available  for 
its  use . 

G.   THE  INNER  TRAFFIC  CONTROLLER 

1 .   General  Description 

The  Inner  Traffic  Controller  is  the  physical 
resource  manager.  It  is  responsible  for  physical  processor 
multiplexing.  Its  principal  data  base  is  a  table  known  as 
the  Virtual  Processor  Map. 

Each  physical  processor  has  its  own  fixed  set  of 
virtual  processors  used  in  multiplexing.  The  Inner  Traffic 
Controller  is  primarily  concerned  only  with  this  set  of 
virtual  processors.  However,  the  performance  of  system-wide 
synchronization  requires  access  to  the  rest  of  the  virtual 
processors  as  well,  so  that  signals  may  be  sent  to  other 
physical  processors.  This  is  accomplished  by  maintaining  the 
Virtual  Processor  Map  as  a  central  data  base  containing 
entries  for  all  of  the  virtual  processors  in  the  system. 
Making  it  globally  available  facilitates  communication 
between  virtual  processors  on  a  system-wide  scale.  The 
Virtual  Processor  Map  fields  are  diagrammed  in  Figure  7. 

The  State  field  reflects  the  present  state  of  the 
virtual  processor  and  can  be  any  of  ready,  running,  waiting, 
or  idle.  A  ready  virtual  processor  is  bound  to  a  process  and 
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is  in  contention  for  the  physical  processor.  The  running 
virtual  processor  is  that  virtual  processor  which  is 
actually  executing  a  process  on  the  physical  processor.  The 
waiting  state  reflects  physical  resource  management.  The 
idle  state  is  assumed  ty  a  virtual  processor  which  has  no 
process  hound  to  it.  The  idle  state  prevents  the  assignment 
of  useless  (idle)  work  to  a  physical  processor. 

The  Priority  field  of  the  virtual  processor  is  used 
in  scheduling.  The  highest  priority  runnahle  virtual 
processor  is  selected  to  run.  This  priority  is  determined  "by 
the  priority  of  the  process  hound  to  the  virtual  processor. 

The  System  Eventcount  Identifier  and  System  Event 
Awaited  fields  are  used  in  system  level  synchronization. 

The  Stack  Segment  Register  Value  field  defines  the 
address  space  of  the  hound  process.  It  holds  the  process 
address  space  descriptor.  The  execution  state  of  the  process 
is  stored  in  the  stack  when  the  process  is  not  actually 
running.  This  is  the  value  which  is  required  to  access  the 
address  space  of  the  process,  viz.,  it  is  changed  to  swap 
processes . 

The  Preempt  Pending  Flag  is  used  for  preemptive 
scheduling.  It  serves  to  virtualize  a  hardware  interrupt 
sent  to  the  physical  processor. 

2.   Virtual  Processor  Scheduler  (Vp_Scheduler) 

This  module  is  responsible  for  making  the  scheduling 
decisions   for  virtual   processors.   It  selects  the  highest 
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priority  virtual  processor  from  among  the  physical 
processor's  assigned  set  of  virtual  processors  and  schedules 
it.  Note  that  there  are  two  distinct  entry  points  to 
Vp_Scheduler. 

The  normal  call  entry  point  is  used  by  other  Inner 
Traffic  Controller  modules  to  activate  Vp_Scheduler  when  a 
virtual  processor  gives  up  the  physical  processor  on  its 
own.  The  preempt  interrupt  entry  point  is  used  in  response 
to  a  hardware  preempt  interrupt  from  another  physical 
processor. 

For  a  normal  call,  Vp_Scheduler  sets  the 
7p_Scheduler  return  type  flag  to  indicate  that  a  normal 
call-return  sequence  is  to  he  followed  for  the  executing 
process.  The  Vp_Scheduler  return  type  flag  is  used  to  keep 
track  of  the  mode  of  entry  into  Vp__ Scheduler  for  the 
process . 

Vp_scheduler  next  searches  through  the  fixed  set  of 
virtual  processors  for  the  highest  priority  ready  virtual 
processor.  In  this  design,  the  definition  of  ready  includes 
the  combination  of  an  idle  state  and  a  pending  virtual 
preempt  interrupt.  This  allows  an  idle  virtual  processor  to 
run  so  that  it  may  field  the  interrupt  and  bind  to  a  new 
process.  The  idle  process  that  was  bound  to  the  virtual 
processor  was  essentially  useless  up  until  this  point.  It 
now  provides  an  address  space  for  the  virtual  processor  to 
execute  in  when  binding  to  a  new  process. 
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Faving  selected  some  eligible  virtual  processor, 
7p_Scheduler  proceeds  to  bind  the  selected  virtual  processor 
to  the  physical  processor.  It  begins  by  unbinding  the 
currently  running  virtual  processor.  In  doing  so,  the 
Vp_Scheduler  return  type  flag,  the  Stack  Pointer  Register 
value,  and  the  rase  Pointer  Register  value  are  saved  in 
known  locations  on  the  orocess'  stack.  The  process' 
execution  state  had  already  been  saved. 

Binding  the  selected  virtual  processor  is  bei?un  by 
changing  the  Stack  Segment  (SS)  Register  value  to  that  of 
the  selected  virtual  processor.  Once  this  change  has  been 
made,  execution  has  actually  swapped  to  the  new  process 
address  space.  Binding  is  completed  by  retrieving  the 
previously  saved  Vp_Scheduler  return  type  flag  for  the  new 
process,  the  Stack  Pointer  Register  value,  and  the  Ease 
Pointer  Register  value  from  the  newly  acquired  stack. 

The  last  step  is  to  actually  check  the  Vp_Scheduler 
return  type  flag  to  determine  the  proper  type  of  return  to 
execute  from  Vp_Scheduler  for  this  process.  If  a  normal 
call-return  is  indicated,  a  normal  return  will  be  executed 
back  through  the  calling  module.  Otherwise,  if  a  preempt 
interrupt  return  is  indicated,  an  interrupt  return  will  be 
executed  and  Check_Preempt  will  see  if  a  virtual  preempt 
interrupt  is  pending.  If  a  preempt  interrupt  is  found  to  be 
pending,  the  Traffic  Controller's  preempt  handler  will  be 
invoked . 
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a.   Internal  Modules 

There   is   ore   internal   module  for  the  Virtual 
Processor  Scheduler   (Vp_Scheduler ) .   It   is   used   for   the 
generation  of  hardware  preempt  interrupts. 
(1)   Hdvr_Int 

This  module  is  called  "by  the  Inner  Traffic 
Controller's  interface  modules  Itc_Advance  and  Send_Freempt. 
It  is  called  with  one  argument,  a  physical  processor 
identifier.  It  then  generates  the  required  hardware 
interrupt . 

3.   Inner  Traffic  Controller  Interface  Modules 
a.   Ioad_Vp 

This  module  performs  the  binding  of  a  new 
process  to  a  virtual  processor.  It  is  called  "by  the  Traffic 
Controller  Scheduler  when  a  process  has   "been   selected   for 

the  virtual  processor.  Load_Vp  requires  two  -oarameters,  the 
priority  of  the  new  process  and  the  address  space  descriptor 
(the  Stack  Segment  Register  value).  It  then  swaps  in  the  new 
process  onto  the  virtual  processor  which  is  currently 
running.  Load_Vp  only  operates  on  the  virtual  processor 
which  is  running  on  the  physical  processor. 

Binding  is  accomplished  by  updating  the  Virtual 
Processor  Map.  The  Inner  Traffic  Controller  utility  function 
Itc_Ret_Vp  is  used  to  obtain  the  identity  of  the  running 
virtual  processor.  When  complete,  the  virtual  Drocessor  will 
have  a  new  priority  and  process   address   space   descriptor. 
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Load_Vp   completes   "by   calling  Vp_Scheduler  to  schedule  the 
virtual  processor. 
b.   Idle_Vp 

This  function  is  Load_Vp's  counterpart.  It  is 
called  by  the  Traffic  Controller  Scheduler  in  the  event  that 
a  runnable  process  is  not  found  for  the  virtual  processor. 
In  this  case  the  virtual  processor  will  be  idled  (enter  the 
idle  state)  and  the  Idle  Process  will  be  bound  to  it.  In  the 
Virtual  Processor  Map,  the  virtual  processor's  state  will  be 
marked  as  idle,  the  address  space  descriptor  for  the  Idle 
Process  will  be  entered  in  the  Address  Space  of  Bound 
Process  field,  and  the  virtual  processor  will  be  given  a 
high  priority.  The  idle  state  ensures  that  the  idle  process 
is  not  actually  run  (the  virtual  processor  now  has  a  high 
priority)  by  taking  the  virtual  processor  entirely  out  of 
contention  for  the  physical  processor. 

At  some  later  point,  the  virtual  processor  may 
be  placed  back  in  contention  for  resources.  This  will  occur 
when  the  virtual  processor  is  preempted.  With  the 
combination  of  an  idle  state  and  a  pending  preempt,  the 
virtual  processor  is  treated  as  a  high  priority  ready 
virtual  processor.  This  allows  the  virtual  processor  to  keep 
busy  by  expediting  its  binding  to  a  process. 

lastly  Idle_Vp  calls  Vp_Scheduler  in  order  to 
give  up  the  physical  processor. 


c.  Itc_F.et_Vp 

This  is  a  "utility"  function  which  is  used  by- 
Inner  Traffic  Controller  and  Traffic  Controller  modules. 
Itc_?et_Vp  searches  the  Virtual  Processor  Map  and  determines 
the  identity  of  the  virtual  processor  that  is  currently 
running  on  the  physical  processor.  It  simply  checks  for  the 
virtual  processor  among  the  virtual  processors  assigned  to 
the  physical  processor  which  is  in  the  running  state. 
Itc_Ret_Vp  then  returns  its  result  as  a  function  value, 
(viz.,  as  in  PL/M)  in  the  AX  (accumulator)  register.  It  will 
return  either  the  identity  of  the  virtual  processor  (the 
virtual  processor's  index  in  the  Virtual  Frocessor  Map)  or  a 
"not  found"  error  code. 

d.  Check_Preempt 

This  module  is  called  "by  Vp_Scheduler  during  the 
execution  of  an  interrupt  return.  It  checks  for  a  pending 
preempt  interrupt  meant  for  the  virtual  processor,  which  has 
been  selected  to  run  by  Vp_Scheduler,  by  checking  the 
virtual  processor's  Preempt  Pending  Flag  in  the  Virtual 
Processor  Map.  If  the  Preempt  Pending  Flag  is  set, 
Check_Preempt  will  reset  it  and  call  the  Traffic  Controller 
module  Tc_?e__Fandler. 

The  module  continuously  loops  as  lon^r  as  it 
finds  the  Preempt  Pending  Flag  set.  This  is  to  ensure  that  a 
new  preempt  interrupt  which  might  arrive  before  servicing  of 
the  last  preempt  is  not  lost. 
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e.  Send_Preempt 

This  module  is  responsible  for  actually  sending 
preempt  interrupts.  It  is  called  "by  the  Traffic  Controller 
Advance  module.  Send_Preempt  requires  two  arguments,  the 
identity  of  the  virtual  processor  which  is  to  he  preempted 
and  the  physical  processor  to  which  that  virtual  processor 
is  assigned. 

Send_Freempt  sets  the  virtual  processor's 
Preempt  Pending  Flag  and  calls  Hdwr_Int  to  generate  a 
hardware  interrupt  for  the  physical  processor.  Hdwr_Int  is 
not  called  if  the  virtual  processor  to  he  preempted  is 
assigned  to  the  physical  processor  which  is  executing 
3end_Preempt ,  (viz.,  a  physical  processor  will  not  issue  a 
hardware  preempt  interrupt  to  itself). 

f.  Itc_Await 

Itc_Await  is  one  of  two  functions  which 
implements  inter-virtual  processor  synchronization  within 
the  kernel.  It  is  not  accessible  to  user  processes,  hut  is 
used  by  the  system  in  the  management  of  physical  resources. 
It  allows  a  virtual  processor  to  wait  for  the  occurrence  of 
a  system  event. 

It  expects  two  input  arguments,  the  index  of  the 
eventcount  in  the  System  Sventcount  Table  and  the  value  of 
the  event  to  be  awaited. 

Upon  being  invoked,  Itc_Await  locks   the   Virtual 
Processor   Map.   It   then   checks   the   current  value  of  the 
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eventcount,  obtained  from  the  System  Eventcor.nt  Table, 
against  the  value  given  in  the  call.  If  the  present  value  of 
the  eventcount  is  found  to  he  less  than  the  value  of  the 
input  argument,  then  the  virtual  processor  will  enter  the 
waiting  state  and  give  up  the  physical  processor. 

The  virtual  processor's  entry  into  the  waiting 
state  will  he  reflected  in  the  Virtual  Processor  Map.  The 
input  arguments  will  he  entered  in  the  Identity  of 
Eventcount  Awaited  and  the  Value  of  Eventcount  Awaited 
fields.  Finally,  the  virtual  processor  will  relinquish  the 
physical  processor  by  calling  Vp_Scheduler.  Upon  a  return 
from  Vp_Scheduler,  the  Virtual  Processor  Map  will  be 
unlocked . 

g.   Itc_Advance 

Itc_Advance  is  used  within  the  kernel  to  signal 
the  occurrence  of  system  events.  It  is  used  with  Itc_Await 
for  synchronization  between  virtual  processors.  It  accepts 
one  input  argument.  This  is  the  index  in  the  System 
Eventcount  Table  of  the  eventcount  to  be  advanced. 

TTpon  being  invoked,  the  Virtual  Processor  Map  is 
locked.  The  System  Eventcount  Table  is  then  accessed  and  the 
indicated  eventcount 's  value  is  incremented  by  one.  The 
resultant  value  is  then  compared  against  the  events  waited 
for  by  other  virtual  processors  which  are  synchronizing  on 
the  same  eventcount.  Those  virtual  processors  v»hose  Value  of 
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Event   Awaited   fields  are  less  than  or  equal  to  the  current 
value  of  the  eventcount  are  made  ready. 

Itc_Advance  then  calls  Vp_Scheduler  to  schedule 
the  virtual  processor.  The  Virtual  Processor  Map  will  "be 
unlocked  upon  a  return  from  Vp_Scheduler . 

H.   THE  TRAFFIC  CONTROLLER 

1 .   General  Description 

The  Traffic  Controller  manages  the  execution  of  user 
processes.  It  presents  to  the  user  a  system  of  one  more 
virtual  processors  on  which  to  execute  his  processes. 

The  Traffic  Controller's  primary  data  "base  is  the 
Active  Process  Table,  shown  in  Figure  8.  The  entry  for  each 
process  in  the  Active  Process  Table  contains  sufficient 
information  about  the  process  to  enable  a  virtual  processor 
to  be  bound  to  and  execute  it.  The  fields  of  the  Active 
Process  Table  are  explained  below. 

The  State  of  a  process  can  be  either  ready,  running 
or  blocked.  A  ready  process  is  one  which  is  not  yet  bound  to 
a  virtual  processor  but  is  ready  to  do  so.  A  running  process 
is  one  which  is  bound  to  a  virtual  processor  and,  as  far  as 
the  process  is  concerned,  executing.  The  blocked  state 
reflects  inter-process  synchronization.  A  process  enters  the 
blocked  state  when  it  realizes  that  it  can  no  longer  proceed 
and  wishes  to  give  up  its  virtual  processor  to  wait  until 
another  process  awakens  it. 
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The  Affinity  field  specifies  the  physical  processor 
that  the  process  must  execute  on.  In  this  system,  this  field 
indicates  the  specific  microcomputer  on  which  the  process  is 
currently  loaded. 

The  Identity  Of  Bound  Virtual  Frocessor  serves  to 
identify  the  virtual  processor,  if  any,  that  the  process  is 
currently  "bound  to. 

The  Priority  specifies  the  priority  of  the  process. 
In  this  system,  priorities  range  in  value  from  0  to  255, 
with  a  priority  of  0  being  the  highest. 

The  Loaded  List  Thread  field  serves  to  implement  the 
Loaded  List  of  ready  and  running  processes.  It  contains  a 
pointer  to  the  next  process  in  the  Active  Process  Table 
which  is  loaded  on  the  same  microcomputer  as  this  process. 
The  loaded  list  is  ordered  "by  the  priorities  of  the 
processes.  Thus,  this  field  contains  either  a  pointer  to  a 
process  whose  priority  is  less  than  or  equal  to  that  of  this 
process  or  a  nil  pointer  (viz.,  the  last  process  on  the 
Loaded  List). 

The  Value  Of  Eventcount  Awaited  reflects  the  event 
for  which  the  process  has  blocked  itself.  It  contains  the 
value  that  the  process  is  waiting  for  the  eventcount  to 
reach. 

The  Block  List  Thread  is  used  to  implement  the 
Blocked  List.  This  is  a  per  eventcount  list  of  processes 
which  are  waiting  on  the  eventcount. 
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The  Address  Space  Descriptor  field  contains  the 
process'  address  space  descriptor.  This  is  the  identity  of 
the  process'  stack  which  contains  execution  point 
information.  The  value  used  here  is  the  base  location  in 
memory  of  the  stack  segment,  viz.,  the  Stack  Segment  fSS) 
Register  value. 

2.   Process  Scheduler  (Scheduler) 

Scheduler  works  in  essentially  the  same  way  that  the 
Inner  Traffic  Controller's  Vp_Scheduler  does.  However, 
Scheduler  works  with  processes.  Scheduler  can  "be  called  by 
Advance,  Await,  Tc_Pe_Handler,  Create_Evc,  Create_Seq,  and 
Create_Frocess. 

It  selects  the  highest  priority  ready  process  from 
the  microcomputer's  Loaded  List  to  "be  bound  to  an  available 
virtual  processor.  Scheduler  works  only  with  the  processes 
which  are  runnable  on  its  own  physical  processor  using-  the 
fixed  set  of  virtual  processors  for  that  physical  processor. 

If  Scheduler  finds  a  runnable  process,  the  Inner 
Traffic  Controller  module  Load_Vp  is  called  to  bind  the 
selected  process  to  the  running  virtual  processor. 
Alternatively ♦  if  a  runnable  process  is  not  found,  the 
virtual  processor  will  he  idled  (hound  to  the  Idle  Process 
and  placed  in  the  idle  state)  by  a  call  to  the  Inner  Traffic 
Controller  module  Idle_Vp. 

In  its  present  form,  Scheduler  has  only  one  entry 
point,  a  call  entry  point.  There  is  no  interrupt  entry  point 
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as  there  is  in  Vp_Scheduler.  This  was  done  as  an  expedient 
in  this  design  effort.  It  is  desireable  to  provide  the 
second  entry  point  so  that  the  two  schedulers  have  parallel 
structures.  Because  there  is  no  interrupt  entry  point,  there 
is  a  loop  between  the  Inner  Traffic  Controller  and  the 
Traffic  Controller  for  the  handling  of  preempt  interrupts. 
This  is  due  to  the  call  from  the  Inner  Traffic  Controller's 
preempt  handler  Check_Pre_Empt  to  the  Traffic  Controller's 
preempt  handler  Tc_Pe_Eandler. 
a.   Internal  Modules 

There  are  two  "utility"  modules  internal  to  the 
Scheduler  that  are  used  only  by  Traffic  Controller  modules. 
They  are  used  to  simplify  the  handling  of  eventcounts  and 
sequencers . 

(1)  Locate_Evc.  This  "utility"  returns  the  index 
of  an  eventcount  in  the  Eventcount  Table.  It  is  called  by 
Advance ,  Await  and  Ticket  with  (a  pointer  to)  the  name  of 
the  eventcount.  Locate_Evc  then  attempts  to  match  the  name 
given  to  it  with  one  in  the  Eventcount  Table.  If  a  match  is 
found,  it  returns  the  index  to  the  caller  in  the  AX 
(Accumulator)   Register   as   a   function   value  (viz.,  as  in 

Pl/M). 

(2)  Locate_Seq.  This  is  the  second  Traffic 
Controller  "utility"  function.  It  works  in  exactly  the  same 
way  that  Locate_Evc  does  except  that  it  searches  for 
sequencers  in  the  Sequencer  Table  rather  than  eventcounts. 
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3.   Traffic  Controller  Interface  Modules 
a.   Await 

Await  allows  a  process  to  suspend  its  execution 
pending  the  occurrence  of  a  specified  event.  AWAIT  is  called 
with  two  arguments,  (a  pointer  to)  the  name  of  the 
eventcount  and  the  value  (of  the  event)  to  he  awaited. 

Upon  invocation.  Await  locks  the  Active  Process 
Table  and  then  calls  the  Inner  Traffic  Controller  utility 
function  Itc_Ret_Vp  to  ohtain  the  identity  of  the  running 
virtual  processor.  This  is  used  in  a  search  of  the  Active 
Process  Table  to  identify  the  calling  process. 

Once  the  calling  process  has  been  identified, 
the  current  value  of  the  eventcount  is  compared  to  the 
awaited  value  specified  in  the  call.  If  the  event  has  not 
yet  occurred,  (viz.,  the  current  value  is  less  than  the 
value  to  be  awaited),  then  the  process  will  enter  the 
blocked  state.  The  Value  of  Eventcount  Awaited  field  in  the 
Active  Process  Table  is  updated  with  the  value  awaited 
argument  and  the  process  is  placed  on  the  eventcount 's 
Blocked  List.  If  the  event  has  already  occurred,  (viz.,  the 
current  value  is  greater  than  or  equal  to  the  value  awaited 
argument),  then  the  process  is  not  blocked  but  is  made 
ready. 

Await  next  calls  Scheduler.   The   Active   Process 
Table  is  unlocked  upon  the  return  from  Scheduler. 
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b.   Advance 

Advance  allows  a  process  to  signal  the  occurrence 
of  an  event.  It  updates  the  eventcount  and  signals  those 
processes  which  had  "blocked  themselves  for  this  event.  Thus 
Advance  is  responsible  for  preemption. 

Advance  is  called  with  one  argument,  (a  pointer 
to)  the  name  of  the  eventcount  being  advanced. 

It  first  locks  the  Active  Process  Table.  Then  the 
current  value  of  the  eventcount  is  incremented.  The 
eventcount 's  Blocked  List  is  searched  for  processes  which 
had  previously  blocked  themselves  for  this  value.  As 
processes  are  found  that  should  be  awakened,  they  are  made 
ready.  An  entry  in  a  temporary  array  of  physical  processors 
is  now  made  to  flag  the  physical  processor,  in  whose  local 
memory  the  newly  awakened  process  is  loaded,  for  preemption. 
The  awakened  process  is  then  removed  from  the  eventcount 's 
Blocked  list. 

Once  all  of  the  processes  to  be  awakened  have 
been  found,  Advance  determines  which  virtual  processors  must 
be  preempted.  This  is  done  for  each  of  the  previously 
flagged  physical  processors  by  first  assuming  that  all  of 
the  physical  processor's  virtual  processors  should  be 
preempted.  Then  the  decision  is  made  as  to  which  ones  will 
not  be  preempted.  This  method  greatly  simplifies  the 
algorithm.  First  a  temporary  list  (array)  of  virtual 
processors  is  initialized  to  indicate  a  virtual  preempt   for 
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each  of  the  virtual  processors.  The  Loaded  List  is  then 
searched  to  find  those  processes  which  should  "be  running. 
The  processes  which  should  he  running  are  those  with  the 
highest  priorities  that  are  in  either  the  ready  or  the 
running  states.  Assuming  there  are  2  virtual  processors  per 
physical  processor  used  for  multiplexing,  the  2  highest 
priority  ready  or  running  processes  in  the  Loaded  List 
should  he  running.  Any  lower  priority  processes  that 
actually  are  running  should  he  preempted.  Advance  determines 
which  of  the  processes  that  should  he  running  already  are 
running  and  deletes  their  virtual  processors  from  the 
preemption  list  (resets  the  preempt  flag  in  the  array).  What 
will  remain  at  the  end  are  those  virtual  processors  that  are 
to  be  preempted. 

The  next  step  is  to  actually  issue  the  preempt 
interrupts.  The  temporary  preempt  list  is  checked  and  if  a 
preempt  is  indicated  for  a  virtual  processor,  the  Inner 
Traffic  Controller  module  Send_Preempt  is  called  to  actually 
issue  the  preempt. 

Advance  next   readies   the   calling   process   and 
calls   Scheduler.  Upon  the  return  from  the  call  to  Scheduler 
the  Active  Process  Table  is  unlocked. 
c.   Ticket 

Ticket  returns  a  unique  sequencer  value  with 
every  invokation.  The  value  returned  will  always  be  one  more 
than  the  last  value  returned. 
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It  is  called  with  one  argument,  fa  pointer  to) 
the  sequencer  name.  When  invoked,  Ticket  asserts  the  global 
lock  on  the  Active  Process  Table,  effectively  locking  the 
Sequencer  Table.  Ticket  then  calls  Locate_Seq  with  the 
pointer  to  the  sequencer  name  given  to  it  as  an  input 
argument  and  gets  hack  the  index  of  the  sequencer  in  the 
Sequencer  Table.  It  then  obtains  the  sequencer's  value  which 
is  to  be  returned  to  the  calling  module  in  the  AX 
(Accumulator)  Register  following:  standard  PI/M  conventions. 
Before  returning,  ticket  increments  the  value  of  the 
sequencer  and  unlocks  the  Active  Frocess  Table. 

Note  that  Ticket  does  net  call  Scheduler  like  the 
other  synchronization  primitives  Advance  and   Await.   Ticket 
returns  immediately  from  a  call, 
d.   Read 

Read  returns  the  current  value  of  an  eventcount. 
It  is  called  with  one  argument,  (a  pointer  to)  the  name  of 
the  eventcount. 

When  called,  Read  locks  the  Active  Process  Table, 
so  as  to  lock  the  Eventcount  Table.  It  then  calls  LocateJEvc 
to  obtain  the  index  of  the  eventcount  in  the  Eventcount 
Table.  With  this  index,  Read  obtains  the  value  of  the 
eventcount  and  returns  the  value  in  the  AX  (Accumulator) 
Register  following  normal  PI/M  conventions.  Prior  to 
returning.  Read  unlocks  the  Active  Process  Table. 
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e.  Tc_Pe_Eandler 

This  module  serves  as  the  virtual  preempt 
interrupt  entry  point  into  Scheduler.  It  is  called  "by  the 
Inner  Traffic  nontroller's  Vp_Scheduler  in  the  course  of 
handling   preempt    interrupts. 

Tc_Pe_Eandler  calls  Scheduler  to  find  the  highest 
priority  ready  process  to  bind  to  the  pre-empted  virtual 
processor. 

f.  Create_Evc 

This  module  creates  an  eventcount  for  a  user 
process.  Create_Evc  is  called  with  one  argument,  (a  pointer 
to)  the  name  of  the  eventcount  to  "be  created. 

Upon  being  invoked,  Create_Evc  locks  the  Active 
Process  Table,  which  effectively  locks  the  Eventcount  Table. 
It  then  calls  Locate_Evc  to  determine  whether  or  not  the 
eventcount  had  already  been  created.  This  is  to  avoid  making 
duplicate  entries  (since  each  process  which  will  use  the 
eventcount  must  declare  at  least  the  name).  If  the 
eventcount  had  not  previously  "been  created  (viz.,  no  entry 
is  found  in  the  Eventcount  Table  with  the  same  name  as  piven 
in  the  input  argument)  then  an  entry  is  made  in  the 
Eventcount  Table.  The  name  is  copied  into  the  Eventcount 
Table  and  the  eventcount's  current  value  is  initialized  to 
0.  Otherwise,  no  entry  is  made.  lastly,  it  unlocks  the 
Active  Process  Table  prior  to  returning. 
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g.   Create_Seq 

This   module   creates   a   sequencer   fcr   a   user 
process.   Create_Seq   performs   in   exactly   the  same  way  as 
Create_Evc  (paragraph  f)  except  that  it   creates   sequencers 
rather  than  eventcounts. 
h.   Create_?rocess 

Create_Process  provides  the  capability  to 
dynamically  create  processes.  It  is  called  with  one 
argument,  a  pointer  to  a  process  parameter  "block  containing 
all  the  information  necessary  to  initialize  the  process's 
stack  and  enter  the  newly  created  process  into  the  Active 
Process  Table.  All  of  the  process's  segments  had  previously 
been  loaded  into  memory  by  the  system  loader,  Foss  [16] . 

Create_Process  first  locks  the  Active  Process 
Table.  It  then  creates  the  ini tializaton  stack  frame.  The 
process  parameter  block  contains  all  of  the  initial  register 
values  (viz.,  initial  values  for  all  of  the  £l?86's 
registers)  for  the  process.  These  are  stored  in  the 
initialization  stack  frame;  the  location  of  the  stack  is 
specified  in  the  Process  Parameter  Block.  The  next  step  is 
to  create  the  Active  Process  Table  entry  for  the  process. 
The  affinity,  priority  and  Stack  Segment  (SS)  Register  value 
are  then  entered  in  the  Active  Process  Table.  lastly, 
Create_Frocess  determines  where  this  process  should  be 
inserted  into  the  Load  list  based  on  its  priority. 
Create_?rocess  inserts  the  process  into  the  Load  List  (viz., 
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sets  the  Load  Thread  in  the  Active  Process  Table) 
immediately  ahead  of  the  first  process  it  finds  in  searching 
down  the  Load^List  whose  priority  is  less  than  or  equal  to 
the  newly  created  process.  Finally,  the  Active  Process  Table 
is  unlocked  and  execution  returns  to  the  caller.  Note  that 
the  Scheduler  is  not  called. 

I.   THE  SUPERVISOR 

In  a  general-purpose  operating  system  the  Supervisor 
provides  common  services  such  as  Horary  routines,  linkers, 
various  development  tools  and  a  file  sytem.  It  also  acts  as 
the  interface  between  user  programs  and  the  kernel. 

1 .   General  Description 

At  this  state  of  the  design,  only  one  module  resides 
at  this  level,  a  higher  order  language  interface  to  the 
operating  system  kernel.  This  module  (called  the  Gate)  is 
constructed  such  that  it  is  the  only  operating  system  module 
that  the  user  must  link  to  his  processes  to  access  kernel 
functions. 

The  Gate  contains  the  actual  linkages  (viz.,  global 
procedure  declarations)  for  all  of  the  kernel  functions. 
This  allows  the  user  to  directly  call  on  various  kernel 
services  without  using  absolute  addresses  that  car.  change  as 
the  kernel  continues  to  be  developed.  This  structure  allows 
the  users  and  the  operating  system  developers  to  continue 
their  work  independently  without   requiring   the  users  to 
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continually  change  their  programs  to  accommodate  changes   in 
the  kernel. 

2.   Supervisor  Invocation  (The  Gate) 

The  C-ate  is  actually  a  set  of  global  (viz.,  PI/M 
PUBLICO  procedure  declarations  which  the  user  programs  can 
call  directly.  Each  of  the  user  accessible  kernel  functions 
is  represented  by  one  of  these  "procedures".  In  reality, 
they  simply  set  up  the  required  parameters  and  use  a  trap 
feature  to  effect  the  call  to  the  "real"  procedure  of  the 
same  name  residing  in  the  kernel. 

The  Gate  is  written  in  assembly  language  because  of 
the  stack  manipulation  that  must  be  done  to  enable  the  trap 
handler  to  l)  determine  the  correct  kernel  procedure  to 
call,  and  2)  properly  pass  parameters  to  the  kernel 
procedures.  The  trap  handler  in  the  kernel  is  an  assembly 
lans-uase  module  as  well.  If  the  trap  handler  were  written  in 
PI/M,  parameters  would  have  to  be  somehow  given  to  it 
explicitly  prior  to  its  calling  on  the  kernel  procedure. 
Since  the  trap  handler  is  reached  by  an  interrupt  rather 
than  a  call,  this  is  not  possible.  Instead,  the  parameters 
are  moved  on  the  stack  to  a  position  where  they  become 
parameters  for  the  call  by  the  trap  handler  to  the  kernel 
procedure. 

This  has  the  effect  of  de-coupling  the  user  from  all 
of  the  operating-  system  modules  below  the  level  of  the 
Supervi  sor . 
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V.   CONCLUSIONS 

A.   SUMMARY  OF  RESULTS 

The  principal  £?oal  of  this  effort  is  the  development  of 
a  multiple  processor  system.  A  parallel  development  effort 
in  secure  systems,  Reitz  [18],  utilized  the  O'Connell  and 
Richardson  design  as  the  "basis  for  the  kernel  of  a  secure 
computer  system  utilizing  the  Zilog  ZB222  microprocessor. 
The  detailed  designs  of  the  kernels  of  "both  of  these  systems 
is  nearly  identical,  at  least  at  the  level  of  kernel  module 
interfaces.  In  both  development  efforts,  no  conceptual 
problems  were  encountered.  Thus  the  O'Connell  and  Richardson 
design  has  been  found  to  be  consistent  for  multiple 
processors  and  secure  computer  systems. 

System  initialization  [16],  introduced  a  number  of 
design  changes.  However,  these  had  no  adverse  effect  on  the 
design  or  the  system.  Their  integration  is  not  a  simple 
matter  as  they  impact  on  the  stack  format,  and  the  design  of 
the  process  scheduler  and  virtual  processor  scheduler  in 
that  the  accommodation  of  preempt  interrupts  is  somewhat 
more  difficult. 

Another  of  the  objectives  is  to  test  the  viability  of 
utilizing  general-purpose,  commercial  microcomputer  systems 
as  the  basic  building  blocks  of  multiple  computer  systems. 
It  has  been  found  that  sufficiently  developed  microcomputer 
systems   are   available   in   industry.    Further,    it    was 
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determined  that  enough  hardware  support  ("busses,  I/O 
devices,  peripherals)  is  available  to  construct  multiple 
computer  systems  without  major  hardware  development  efforts. 

The  state  of  the  art  in  microcomputer  software 
development  was  found  to  he  less  amenable.  Such  useful  tools 
as  high  level  languages,  assemblers,  etc.  are  available  but 
they  are  generally  limited  to  use  with  uniprocessor 
developmental  systems.  Additionally,  most  commercially 
available  software  development  tools  are  highly  machine 
dependent.  Specifically,  they  require  low-level  monitors  or 
special  hardware  that  are  only  available  on  a  development 
system.  Thus  there  is  little  hope  of  easily  modifying  these 
tools  to  run  on  a  different  system  than  was  intended  by  the 
vendor,  particularly  since  details  of  their  structure  and 
operation  are  proprietary. 
A.   FURTHER  RESEARCH 

Further  development  work  is  still  required.  This 
includes  the  final  construction  of  the  Gate  and  the 
inclusion  of  two  non-distributed  kernel  processes  for  I/O 
and  memory  management.  These  kernel  processes  provide  for 
the  virtualizat ion  of  memory  and  I/O  resources  with  which  to 
achieve  the  goal  of  configuration  independence. 

The  present  design  utilizes  the  test-and-set  semaphore 
operation  to  implement  global  locks  on  kernel  data  bases 
(viz.,  the  Active  Process  Table  and  the  Virtual  Processor 
Map).   This   mechanism   (supported   by   the   PL/M   built-in 
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procedure  "Lockset"  [5])  is  a  spin-lock  with  potentially 
significant  impact  on  system  bus  traffic.  This  mechanism 
should  he  replaced  "by  the  Inner  Traffic  Controller 
synchronization  primitives  wherever  possible  to  avoid  the 
overhead  of  "busy-waiting". 

This  detailed  design  is  considered  to  be  only  a  first 
step  in  the  development  of  a  general-purpose  multiple 
microcomputer  system.  O'Connell  and  Richardson's  design 
offers  some  exciting  opportunities  to  pursue  development 
efforts  in  the  areas  of  secure  computer  systems  and  fault 
tolerance . 
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APPENDIX  A  -  PROGRAMMING 

A.   INTRODUCTION 

This  appendix  is  designed  to  "be  a  practical  introduction 
to  programming  methodology  for  this  system. 

Because  there  are  multiple  processors,  a  number  of 
concepts  and  methodologies  will  necessarily  be  introduced 
which  may  at  first  be  uncomfortable.  This  is  especially  true 
if  one  is  firmly  entrenched  in  the  traditional  concepts  of 
the  monolithic,  sequential  program  structure.  However,  as 
one  makes  the  transition  to  the  concepts  of  process 
structuring,  it  will  be  seen  to  be  a  natural  approach  to  the 
development  of  complex  software  systems.  Additionally,  it  is 
essential  to  the  effective  use  of  multiple  processor 
systems . 

Parallelism  immediately  presents  the  programmer  with  an 
entirely  new  set  of  complexities.  He  is  not  limited  to  the 
strictly  sequential  execution  of  program  statements  in  a 
single  program.  Exercising  control  over  the  order  and  timing 
of  execution  of  multiple  processes  becomes  a  major  part  of 
the  programming  effort.  Inter-process  synchronization,  the 
mechanism  by  which  processes  are  controlled,  is  the  most 
difficult  concept  which  the  user  will  be  required  to  deal 
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with.  However,  the  synchronization  primitives  built  into  the 
operating  system  are  designed  tc  make  this  as  simple  and 
straightforward  as  possible. 

It  is  assumed  that  the  primary  programming  language  for 
this  system  will  be  Intel's  PI/M-86  [5,  10] .  This  is  a 
powerful,  block  structured  high  level  language  designed  for 
systems  programming.  This  appendix  is  written  assuming  that 
the  reader  will  program  in  PL/M-S6  and  is  familiar  with  its 
terminology  and  notation.  All  of  the  examples  make  use  of  an 
informal  PL/M  notation. 

B.   THE  PROCESS  STRUCTURE 

Consider  the  rather  typical  PL/M  program  module  of 
Figure  9.  It  contains  three  procedure  declarations  and  some. 
mainline  statements.  Each  of  the  procedures  will  execute 
when  called  from  the  mainline  and,  upon  completion,  will 
return  control  back  to  the  mainline. 

A  single  program  is  what  most  users  are  familiar  with 
and  is  a  structure  which  can  be  dealt  with  easily.  However, 
as  the  computing  task  grows  to  any  real  size  and  complexity, 
this  single  program  grows  equally  large  ard  complex.  The 
result  is  a  huge  program  with  a  myriad  of  procedures  that 
can  only  be  called  sequentially  to  perform  necessary 
functions.  Thus  this  structure  does  not  allow  taking 
advantage  of  the  performance  ^ain  that  parallel  processing 
can  offer. 
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Program  Module  A:  Do; 

HI:   PROCEDURE  /*  Declaration  */; 

do; 


end; 

END;  /*  Procedure  U  */ 

A2:  PROCEDURE;  /*  Declaration  */ 

do; 


end; 
END;  /*  Procedure  A2  */ 

A3:  PROCEDURE;  /*  Declaration  */ 

do; 


end; 

END;  /*  Procedure  A3  */ 

DO;  /*  Begin  Mainline  */ 

CALL  All 
CALI  A2J 
CALL  A3; 

END;  /*  Mainline  */ 
END;  /*  Program  Module  A  */ 


EXAMPLE    PL/M-36    PROGRAM 
Figure    9 
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Start 
Processing 


Loop   "back 
to    start 


THREE  PROCESSES  EXECUTING  SEQUENTIALLY 
Figure  12 


DECLARE  MAKEl(S)  BYTE  DATA  ('NAME1%')J 

Eyte  array  of  String  constant 
length  6  to  hold  name  defined  by 
the  name  the  user 


DECLARATION  OF  EVENTCOUNT  AND  SEQUENCER  NAMES 

Figure  11 


75 


The  principal  advantages  of  the  process  structure  lie  in 
the  ability  to  utilize  multiple  processes  and  tc 
independently  construct  individual  components  of  software 
subsystems,  viz.,  processes.  Rather  than  using  a  single 
process  to  accomplish  the  entire  job  as  in  Figure  9,  the 
overall  task  can  be  partitioned  and  accomplished  by  a  number 
of  smaller  cooperating  processes.  Each  of  these  processes 
can  be  smaller  than  the  single  monolithic  program  and  so  is 
easier  to  design,  implement  and  test.  This  allows  entire 
processes  (each  a  distinct  program)  to  be  developed  and 
tested  semi-independently  in  a  manner  similar  to  the 
development  and  testing  of  individual  procedures  in  a  single 
PL/M  program. 

Control   over  processing  functions   is   also  much  more 

flexible.  One  is   not   forced   into  a   strictly   sequential 

i 

series  of  procedure  calls.  Many  processes  can  be  allowed  to 
execute  in  parallel,  which  can  bring  about  draratic  pains  in 
overall  performance. 

Figure  10  is  a  simple  example  of  the  flow  of  execution 
in  a  system  with  three  processes.  The  three  processes 
perform  exactly  the  same  functions  as  the  three  procedures 
of  Figure  9  and  so  bear  the  same  names.  In  this  example  the 
processes  execute  sequentially,  one  after  the  other  in  a  set 
order.  Processing  goes  on  forever  in  this  "loop".  Frccess  A2 
will  only  begin  executing  after  it  has  been  somehow 
"signalled"   by  process   Al .  The  same  is  true  of  process  A? 
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whose  execution  is  synchronized  with  process  A2.  Obviously, 
there  must  be  sorre  control  mechanism  that  allows  these 
processes  to  do  this. 

C.   I  NT EH -PROCESS  SYNCHRONIZATION  MECHANISMS 

The  ability  to  synchronize  the  execution  of  processes 
throughout  the  system,  (irrespective  of  which  microcomputer 
they  are  loaded  on),  is  the  cornerstone  of  the  power  and 
flexibility  of  this  system.  To  accomplish  this,  process 
synchronization  is  based  on  the  notion  of  events. 

1.   Events 

An  event  is  anything  that  one  considers  significant 
and  can  direct,  in  some  fashion,  the  computer  to  respond  to. 
As  an  example,  consider  a  clock  which  indicates  a  time  of 
twelve  o'clock.  The  computer  has  no  inherent  conception  of 
time.  As  far  as  it  is  concerned,  time  may  be  nothing  more 
than  a  value  in  some  register.  In  some  way,  then,  time  must 
be  defined  for  the  computer.  This  is  accomplished  by 
translating  the  occurrence  of  twelve  o'clock  into  an  event. 
When  the  event  occurs,  the  computer  recognizes  that  it  is  to 
respond  in  some  specified  manner. 

Events  are  defined  so  as  to  be  very  general  in 
nature.  They  can  be  used  to  represent  the  completion  of  a 
program,  as  in  the  completion  of  process  Al  in  Figure  12 
which  started  tne  execution  of  process  A2.  They  can 
represent   virtually  anything  of  interest  to  the  programmer, 
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at   least   anything   that   he   can   identify   as   being    of 
significance . 

2.   Eventcounts  and  Sequencers 

Eventcounts  and  sequencers  allow  processes  to 
synchronize  with  each  other  somewhat  indirectly.  To 
synchronize  directly,   a   process   would  have   to   somehow 

identify  the  other  processes  with  which  it  is   synchronizing 
(viz.,   explicitly  signal   a  process   by  name).  This  would7 
require  the  naming  of  individual  processes  or   some   similar 
identification  scheme. 

Rather  than  using  a  process  naming  scheme,  the 
individual  processes  "agree",  in  a  sense,  to  cooperate  by 
using  a  common  set  of  memory  objects  called  eventcounts  and 
sequencers.  In  this  way,  even  though  the  processes  must  know 
the  names  of  the  eventcounts  and  sequencers  that  they  use, 
they  are  not  required  to  know  anything  at  all  about  each 
other's  identities.  In  fact,  a  process  need  not  even  know- 
how  many  other  processes  will  tbe  synchronizing  with  it. 
This  offers  some  advantages  in  parallel  processing. 
Processes  that  synchronize  with  eventcounts  do  not  have  to 
know  how  many  other  processes  will  also  use  the  same 
eventcounts.  This  means  that  fewer  coding  changes  will  be 
required  when,  for  example,  a  single  process  is  partitioned 
into  several  processes  all  executing  in  parallel.  All  of  the 
"new"  processes  will  synchronize  on  the  same  eventcount  so 
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that   no  changes  are  required  in  the  process  that  originally- 
synchronized  with  the  single  process. 

Eventcounts  are  used  to  keep  track  of  the  occurrence 
of  specific  events.  They  are  managed  for  the  user  "by  the 
system.  Eventcounts  are  implemented  as  PI/M-66  word 
variables  ranging  in  value  from  0  to  65536.  Sequencers  are 
also  implemented  as  FL/M-66  word  variables  ranging  in  value 
from  0  to  65536.  However,  sequencers  can  be  used  to  impose 
an  order  on  the  occurrence  of  events.  They  are  thus  used 
with  eventcounts  to  provide  for  mutual  exclusion. 
3.   Eventcount  and  Sequencer  Teclaration? 

a.   Declaring  Eventcount  and  Sequencer  Names 

Eventcounts  and  sequencers  are  named  using  a 
byte  array  of  alphanumeric  characters.  The  format  for 
declaring  an  eventcount  or  sequencer  name  is  given  in  Figure 
11.  Note  that  the  names  are  constants,  not  variables.  Once 
declared,  a  name  must  not  change.  Eventcount  and  sequencer 
names  consist  of  5  characters  followed  by  a  per  cent  symbol 
(%).  Note  in  Figure  11  that  the  name  of  the  byte  array  must 
be  the  same  as  the  string  constant  given  in  the  TATA 
Initialization.  This  allows  the  user  to  reference  the 
eventcount  or  sequencer  by  name  and  allow?  the  operating 
system  to  identify  it. 

Remember  that  the  names  of  eventcounts  and 
sequencers  must  be  declared  in  exactly  the  same  way  in  each 
PL/M-86  module  in  which  they  will  be  used. 
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b.  Passing  Eventcount  and  Sequencer  Names 

When  calling  the  operating  system 
synchronization  primitives,  eventcount  and  sequencer  names 
are  always  passed  as  PI/M-S6  location  references  using  the 
"<?'  operator.  As  an  example,  consider  that  a  "byte  array 
called  "NAMEl"  holds  the  string  "WAME1%"  (note  that  the  "%" 
symbol  is  only  a  delimiter  and  is  not  considered  to  he  part 
of  the  name).  To  pass  the  name  in  a  call  to  an  operating 
system  synchronization  primitive,  then,  the  parameter 
"GNAMEl"  is  used.  With  the  pointer  so  given,  the  operating 
system  can  "read"  the  name  directly  from  the  array. 

c.  Creating  Eventcounts  and  Sequencers 

before  an  eventcount  or  a  sequencer  is  used,  the 
operating  system  must  he  informed  cf  its  existence.  This  is 
accomplished  by  a   call  to  the  operating  system  procedures 

CREATE$EVC  (for  eventcounts)  and  CREATEsSEC  (for 
sequencers).  The  format  of  these  operations  is  shown  in 
Figures  12  and  13.  There  is  only  one  argument  for  either  of 
the  calls,  the  pointer  to  the  previously  declared  name.  Tihen 
created,  an  eventcount  or  a  sequencer  will  always  te 
initialized  with  a  starting  value  of  0. 
4.   Synchronization 

Eventcounts  and  sequencers  are  utilized  hy  means  cf 
a  set  of  operations  which  may  he  performed  on  them.  The  user 
cannot  directly  perform  operations  on  either  eventcounts  or 


ee 


CALL 


CREATE$E7C(GNA?1E1)  J 

Kernel     Pointer  to 
function    the  head  of  the 
name       pre-declared 

byte  array  holding 
the  string  name 


CREATING  AN  EVENTCOUNT 
Figure  12 


CALL 


CHEATE$SEC((?NAME1); 

Kernel     Pointer  to 
function    the  head  of  the 
name       pre-declared 

"byte  array  holding 
the  string  name 


CREATING  A  SEQUENCER 
Figure  13 
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sequencers,   "but   rather   calls   on  certain  operating  system 
primitives  to  do  these  for  him. 

a.   Operations  on  Eventcounts 

There  are  three  operations  that  one  can  perform 
on  eventcounts.  They  are  ADVANCE,  AWAIT  and  READ.  ADVANCE 
and  AWAIT  are  untyped  procedures.  BEAD  is  a  value  returning' 
typed  procedure  (function  call)  that  returns  a  PL/M-86  word 
value  to  the  calling  process. 

An  example  of  a  READ  operation  is  fiven  in 
Figure  14.  The  READ  operation  allows  the  user  tc  octain  the 
current  value  of  a  specified  eventcount.  READ  returns  the 
eventcount's  value  in  the  AX  Register  (in  accordance  with 
normal  PL/M-66  conventions).  Thus  a  process  calls  READ  with 
the  name  of  the  eventcount  as  the  argument  and  gets  hack  the 
eventcount's  current  value.  Note  in  Figure  14  that  the 
current  value  of  eventcount  EVENT  is  returned  to  the 
user-defined  word  variable  "WO?J)$  VARIABLE" . 

The  AWAIT  operation,  Figure  15.  is  use!  ty  a 
process  to  "block  itself  (suspend  its  execution)  until  the 
eventcount  reaches  the  value  specified  in  the  call.  AWAIT 
requires  two  arguments,  the  eventcount  name  and  the  event 
(actually  the  value  of  the  eventcount)  to  wait  for.  The 
value  for  which  the  process  will  wait  must  he  a  PI/N-86  word 
value.  This  allows  the  process  to  synchronize  itself  with 
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WOR  INVARIABLE  =  READ(0EVENT )  J 


TEE  READ  OPERATION 
Figure  14 


CALL  AWAIT(0EVENT,VAIUE$TO$AWAIT)i 


THE  AWAIT  OPERATION 
Figure  15 


CALL  ADVANCE (0EVENT) J 


THE  ADVANCE  OPERATION 
Figure  16 


WORD$VARIABIE  =  TICKET  (GNAME1 ) » 


THE  TICKET  OPERATION 
Figure  17 
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other  processes  by  waiting,  for  instance,   until   a   set   of 
data  is  ready  for  it  to  use. 

The  ALVANCE  operation,  Figure  16,  is  used  to 
signal  the  occurrence  of  an  event.  ADVANCE  only  requires  one 
argument,  the  nane  of  the  eventcount  to  be  advanced.  When  it 
is  called,  it  will  cause  the  value  of  the  eventcount  to  be 
incremented  by  one.  The  operating  system  will  then  proceed 
to  unblock  those  processes  that,  were  waiting  for  the 
eventcount  to  reach  the  current  value  (by  virtue  of  having 
previously  called  AWAIT). 

b.   Operations  on  Sequencers 

There  is  only  one  operation  that  can  be 
performed  on  sequencers.  It  is  called  TICKET,  Figure  17. 
TICKET  is  a  value  returning  typed  procedure  (function  call) 
similar  to  the  READ  operation  for  eventcounts.  However, 
TICKET  returns  to  the  caller  a  unique  sequencer  value.  The 
current  value  of  the  sequencer  is  returned  to  the  caller  and 
then  the  sequencer  is  incremented  by  one  for  the  next  caller 
time  a  TICKET  operation  is  performed  on  it.  This  will  be 
true  irrespective  of  how  many  different  processes  perform 
the  TICKET  operations.  In  this  way  TICKET  provides  the 
totally  ordered  set  of  values  for  use  by  multiple  processes 
in  effecting  mutual  exclusion. 
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5.   Synchronization  Examples 

a.   Sequential  Processing  Example 

Figure  IS  provides  a  detailed  example  of  how  a 
process  would  be  programmed  to  actually  create  and  use 
eventcounts  for  synchronization.  The  pros-ram  shewn  here  is 
actually  process  Al  of  Figure  10. 

Referring-  to  the  flow  of  control  in  Figure  10, 
it  can  he  seen  that  process  A2  will  begin  execution  when 
signalled  by  Al.  Similarly  process  A3  will  begin  when 
signalled  "by  A2.  Finally,  when  A3  signals  its  completion, 
the  "loop"  starts  over  again  with  process  Al .  This  is 
reflected  in  the  sample  program  for  process  Al,  Figure  10. 
Here  two  eventcounts  are  declared  and  created,  "ENEAl"  and 
"ENDA3" .  Event  count  ENDA1  is  used  to  synchronize  with 
process  A2.  Specifically,  ENDA1  refers  to  the  event 
corresponding  to  the  completion  of  Al 's  processing  task.  The 
occurrence  of  this  event  is  signalled  to  process  A2  through 
the  Advance  operation  performed  on  eventcount  ENDA1  (located 
at  the  end  of  the  "To  Forever"  loop).  The  result  of  the 
Advance  is  to  start  the  execution  of  process  A2.  After  the 
call  to  Advance,  process  Al  will  loop  back  to  the  call  to 
Await  with  an  awaited  value  of  1  this  time  and  (if  process 
A3  has  not  yet  advanced  EN33A3)  will  wait  there. 

Process  A2  is  programmed  as  shown  in  Figure  13. 
Note  that  it  first  calls  Await  with  the  eventcount  ENLA1  and 
an  awaited  value  of  1.  This  is  in  contrast  to  the  awaited 
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PROGRAM  MODULE  Al:  DO; 

/*  Teclare  Sventcounts  */ 

DECLARE  ENDA1(6)  5TTE  DATA  ('ENDA1%'); 

DECLARE  ENDA3(6)  BYTE  DATA  ('ENDA3%'); 

/*  Declare  a  local  word  variable  */ 
DECLARE  A1<?AGAIN  WORD; 

/*  Declare  Synchronization  Primitives  */ 
CREATEiEVC:  PROCEDURE (EVENT COUNT )  EXTERNAL; 

declare  eventcount  pointer  j 
end; 
await:  procedure(eventcount,  value)  external; 

DECLARE  EVENTCOUNT   POINTER, 
VALUE      word; 
end; 
advance:  ppocedure(eventc0unt )   external? 

declare  eventcount  pointer; 
end; 

/*  Pegin  Mainline  */ 

AliAGAIN  =  0;  /*  To  start  execution  immediately  */ 
CALL  CREATESEVC(GENDAI);  /* 
CALL  CREATE$EVC(C=ENDA3); 

DO  WHILE  l;  /*  Do  Forever  */ 

/*  Check  to  see  if  processing  should  begin  */ 
CALL  AWAIT  (GENDA3, AlU&AIN )  J 


/*  Processing  completed  so  notify  process  A2  */ 

CALL  ADVANCE(GENDA1 ); 

/*  Increment  the  value  to  await  */ 

AlSAGAIN  =  AlSAGAIN  +  If 

END;  /*  Of  Do  Forever  */ 
END;  /*  Module  */ 


EXAMPLE  CODE  FOR  PROGRAM  Al 
Figure  16 
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PROGRAM 'MODULE  A2:  DO? 

/*  Declare  Eventcounts  */ 

DECLARE  SNDA1(6)  PYTE  DATA  ('ENDA1%')J 

DECLARE  ENDA2(6)  2YTE  DATA  ('ENDA2%'); 

/*  Declare  a  local  word  variable  */ 
DECLARE  A 2$ A GAIN  WORD? 

/*  Declare  Synchronization  Primitives  */ 

create$evc:  procedure (eventcotlmt  )  external; 

declare  eventcount  pointer; 
end; 

await:  procedure (eventcount, value)  external; 

declare  eventcount  pointer, 
VALUE      word; 
end; 
advance:  procedure(eventcount )  external; 

declare  eventcount  pointer; 
end; 

/*  Be^in  Mainline  */ 

A2$AGAIN  =  l;  /*  To  start  execution  after  process  Al  */ 
CALL  CREATE$EVC(GENDA1);  /* 
CALL  CREA?E$EVCfGENDA2) ; 

DO  WFILE  i;  /*  Do  Forever  */ 

/*  Check  to  see  if  processing:  should  be^in  */ 
CALL  AWAIT (0ENDA1,A2$ AGAIN); 


/*  Processing  completed  so  notify  process  A3  */ 

CALL  ADVANCE(0ENDA2); 

/*  Increment  the  value  to  await  */ 

A2SAGAIN  =  A2SAGAIN  +  15 

END;  /*  Of  Do  Eorever  */ 

END;  /*  Mcdule  */ 


EXAMPLE  CODE  FOR  PROGRAM  A2 
Figure  19 
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PROGRAM  MODULE  A3:  DC  J 

/*  Declare  Even  tcoun  ts  :::/ 

DECLARE  ENDA2(6)  BYTE  DATA  ('ENDA2%'); 

DECLARE  ENDA3(6)  3YTE  DATA  ('ENDA3%'); 

/*  Declare  a  local  word  variable  */ 
DEC I ARE  A 3$ A  GAIN  WORD; 

/*  Declare  Synchronization  Primitives  */ 

create$fvc:  proceb*jbe(  event  count  )   external,* 

declare  evsntcount  pointer; 
end; 

hwait:  procedure (eventcount, value)  external; 
declare  eventcount  pointer, 
VALUE      word; 
end; 
advance:  procedure ( eventcount )  external; 

declare  eventcount  pointer; 
end; 

/*  Eegin  Mainline  */ 

A3SAGAIN  =  i;  /*  To  start  execution  after  process  A2  */ 
CALL  CREATESEVC(C-ENDA2);  /* 
CALI  CREATESSVC(GENDA3);  . 

DO  WHILE  l;  /*  Do  Forever  */ 

/*  Check  to  see  if  processing  should  "begin  */ 
CALL  AWAIT(0SNDA2,A3$AGAIN); 


/*  Processing  completed  so  notify  process  Al  */ 

CALL  ADVANCE(PENDA3); 

/*  Increment  the  value  to  await  */ 

A3SAGAIN  =  A3$AGAIN  +  i; 

END;  /*  Of  Do  Forever  */ 

END?  /*  Module  */ 


EXAMPLE  CODE  FOR  PROGRAM  A3 
Figure  20 
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value  of  0  used  by  process  Al  in  its  initial  call  to  Await. 
Thus  process  A2  will  wait  at  this  point  until  signalled  by 
process  Al  (if  process  A2  begins  executing  before  process 
Al).  After  Al  performs  an  Advance  on  eventcount  ENEA1,  A2 
will  perform  its  processing  and  when  complete  will  signal 
process  A?  to  begin  via  an  Advance  operation  on  the 
eventcount  ENBA3.  As  with  process  Al,  it  will  then  loop  back 
to  the  Await  operation  and  will  be  suspended  until  Al  once 
again  signals  it  to  continue. 

Figure  2£  shows  the  program  for  process  A3. 
Process  A3  performs  an  initial  Await  as  the  others  did  and 
when  its  processing  task  has  been  completed,  it  signals 
process  Al  to  begin  the  "loop"  again  via  an  Advance 
operation  on  eventcount  ENM3. 

These  three  processes  are  intended  to 
demonstrate  the  mechanics  of  synchronizing  with  eventcounts. 
As  can  be  seen,  the  operations  used  in  all  three  of  the 
processes  are  very  similar.  The  real  differences  lie  only  in 
the  specific  eventcounts  that  each  process  uses  in  the  calls 
to  Await  and  Advance.  Note,  however  that  each  process 
performs  the  Await  operation  at  a  point  that  ensures  the 
process  will  be  synchronized  with  its  companion  processes 
even  if  the  process  begins  "out  of  order".  This  is  required 
to  avoid  confusion  since  there  is  no  guarantee  that  the 
first  of  the  three  processes  to  begin  executing  will  be  the 
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one  intended  by  the  programmer  to  execute  first  (viz.,  Al  in 
this  example )  . 

b.   Parallel  Processing  Example 

Suppose  that  instead  of  the  simple  sequential 
execution  of  processes,  as  in  the  above  example,  one  wishes 
to  execute  processes  in  parallel.  The  eventcount  mechanism 
provides  the  capability  to  synchronize  parallel  processes  in 
(mechanically)  the  same  way  that  sequential  processing  is 
accomplished . 

Consider  again  the  three  processes  Al ,  A2,  and 
A3  from  the  previous  example.  This  time  the  programmer  notes 
that  processes  A2  and  A3  both  depend  on  input  data  (a  set  of 
filter  coefficients,  for  example)  from  process  Al .  However, 
he  also  notes  that  neither  process  A2  nor  A3  alters  the 
input  data  (they  only  read  it).  Thus  processes  A2  and  A3 
become  candidates  for  parallel  execution  since  they  both 
have  a  common  event  upon  which  to  begin  execution  (the  point 
where  the  input  data  becomes  available)  and  they  do  not 
depend  on  each  other.  Note,  however,  they  must  reside  in 
different  microcomputers  for  their  execution  to  actually 
occur  in  parallel. 

The  desired  flow  of  execution  is  showr  in  Figure 
21.  Implementing  the  parallel  execution  of  processes  A2  and 
A3  is  actually  a  simple  task.  Only  process  A3  need  be 
changed.  Processes  A2  and  A3  await  the  same  value  of  a 
common  eventcount  rather  than  different  ones.  Thus  the 
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PLOW  OF  CONTROL  IN  PARALLEL  PROCESSING 
Figure  21 
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PROGRAM  MODULE  A3:  DO? 

/*  Declare  eventcounts  */ 

/*  Eventcounts  ENDA1,  ENDA2  and  ENEAS    */ 

/*  Declare  a  local  word  variable  */ 
DECLARE  A3$AGAIN  WORD? 

DECLARE  ENDAl(e)  BITE  DATA  ('ENLA1%'); 
DECLARE  ENDA2(6)  BYTE  DATA  ('ENDA2%')j 
DECLAPE  ENDA3(6)  BYTE  DATA  ('ENDA3%')J 

/*  Declare  synchronization  primitives  */ 
/*         Advance  and  Await  */ 

/*  Begin  Mainline  */ 
/*  Create  the  eventcounts  */ 
A3$AGAIN  =  i; 
DO  WHILE  1J  /*  Do  forever  */ 

CALL  AWAIT(PENDA1,A3$AGAIN); 

/*   Perform  processing   */ 

• 

/*  Processing  of  "both  A2  and  A3  complete  */ 
CALL  AWAIT(0ENDA2,A3$AGAINK 
CALL  ADVANCE(GENDA3) » 

/*  Increment  the  value  to  await  */ 
A3$ AGAIN  =  A3$AGAIN  +  1J 

END;  /*  Of  Do  Forever  */ 

END?  /*  Of  Module  */ 


PARALLEL  PROCESSING  EXAMPLE  PROCESS  A3 
Figure  22 
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result  of  a  single  Advance  on   the   eventcount   will   be   to 
simultaneously  signal  processes  A2  and  A.3. 

The  operations  performed  "by  process  A3  is  shown 
in  Figure  22.  Process  Al  is  still  required  to  perform  its 
processing  first  to  provide  input  data  for  processes  A2  and 
A3.  Thus  process  Al  performs  an  initial  Await  operation  on 
the  eventcount  ENDA3  with  an  awaited  value  of  ?■ ,  and  since 
the  eventcount  is  initialized  to  a  value  of  0  upon  creation, 
Al  will  he  allowed  to  continue.  Processes  A2  and  A3  "both 
perform  their  initial  Await  operations  on  the  eventcount 
ENDA1  using  the  same  awaited  value  (they  each  wish  to  "begin 
processing  when  the  set  of  input  data  becomes  available). 
However,  process  A3  will  advance  the  value  of  ?.MTA3  only 
after  both  A2  and  A3  have  completed.  This  allows  Al  to  wait 
for  the  two  events  to  occur  (viz.,  the  completion  of 
processes  A2  and  A3)  before  it  begins  again.  Thus  with  the 
single  Advance  operation  performed  by  Al  on  EN DAI  two 
processes  begin  execution. 

This  example  has  shown  how  the  programmer  can 
easily  make  use  of  eventcounts  to  synchronize  parallel 
processes  with  the  same  methodology  used  for  sequential 
processes . 

c.  Mutual  Exclusion  Example 

Mutual  exclusion  is  required  in  certain 
situations  where  one  and  only  one  process  can  be  allowed  to 
access  a  shared  resource  (some  set  of  data)  at  a  time. 
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MUTUAL  EXCLUSION  EXAMPLE 
Figure  23 
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PROGRAM  MODULE  PRINTER  PROCESS:  TO; 

/*  Declare  eventcounts  FULLB  and  EMPTY,  used  */ 
/*  by  all  of  the  processes  */ 

DECLARE  FULLB(6)  BYTE  DATA  ('FULIB%'); 
DECLARE  EMPTY(6)  BYTE  DATA  ('EMFTY%')J 

/*  Declare  a  local  word  variable  */ 
DECLARE  AGAIN  WORDJ 

/*  Declare  synchronization  primitives  */ 
/*         Advance  and  Await  */ 

/*  Begin  Mainline  */ 
/*  Create  the  eventcounts  */ 
DO  WHILE  i;  /*  Do  forever  */ 

C*LL  AWAIT (PFULLB, AGAIN); 

/*   Perform  processing   */ 

• 

/*  Processing"  complete,  notify  others  #/ 
/*  that  buffer  is  available  */ 

CALL  ADVANCE(OEMPTY); 

/*  Increment  the  value  to  await  */ 
AGAIN  =  AGAIN  +  1J 

END;  /*  Of  Do  Forever  */ 

END;  /*  Of  Module  */ 


PF INTER  PROCESS  FOR  MUTUAL  EXCLUSION  FJ AMPLE 

Figure  24 
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PROGRAM  MODULES  Al  THROUGH  Ak:  DO; 

/*  Declare  eventcounts  FULLB  and  a  sequencer  */ 
/*  used  "by  all  of  the  processes.   Sequencer  */ 
/*  "by  all  of  the  processes.   Sequencer  is    */ 
DECLARE  FUIIB(6)  BYTE  DATA  (  'FULLE% ' )  ; 
DECLARE  EMPTY (6)  BYTE  DATA  ('EMPTY%'); 
DECLARE  TURNA(6)  BYTE  DATA  ('TURNA%')i 

/*  Declare  some  local  variables  among  which  is 
DECLARE  T  WORD  J 

/*  Declare  synchronization  primitives      * f 
/*  Advance  and  Await  as  before  plus  Ticket  */ 
TICKET:  PROCEDURE (SEOUFNCER)  WORD  EXTERNAL; 
DECLARE  SEQUENCER  POINTER; 


end; 


/*  Begin  Mainline  */ 


/*  At  this  point  process  needs  to  print  data  */ 

/*  so  create  the  eventcounts  as  usual  and  create  */ 

/*  the  sequencer  */ 
CALL  CREATE$SE9(GTUP.NA)  ; 

/*  Obtain  a  "turn"  for  the  buffer  */ 
T  =  TICKET (GTURN A) J 

/*  Wait  for  "turn"  to  come  up  * 
CALL  AWAIT (0EMFTY,T)i 

/*  When  awakened,  process  may  use  the  */ 
/*  buffer  (its  "turn"  has  come  up)    */ 

/*  Finished  with  the  buffer  so  notify  */ 
/*  Printer  Process  that  there  is  output  */ 
CALL  ADVANCE(GFULLB); 

END;  /*  Of  Module  */ 


PROCESSES  Al  -   Ak  FOR  MUTUAL  EXCLUSION  EXAMPLE 

Figure  25 
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Sequencers  are  used  in  conjunction  with  event  counts  to  solve 
these  types  of  problems. 

To  illustrate  mutual  exclusion,  consider  the 
flow  of  control  in  Figure  23.  Here  an  unknown  number  of 
processes  (Al  through  Ak)  require  access  to  a  single 
resource  (use!  "by  A3).  Printer  Process  is  some  printer 
service  and  the  single  shared  resource  is  its  input  buffer. 
Obviously  only  one  of  the  processes  requesting  printer 
services  can  be  allowed  to  write  into  the  input  buffer  at  a 
time  and  no  process  can  write  into  the  buffer  while  Printer 
Process  is  trying  to  transfer  the  information  to  the 
printer. 

The  solution  is  shown  in  Figures  24  and  25. 
Figure  24  shows  the  programming  of  Printer  Process  and 
Figure  25  shows  how  each  of  the  processes  requiring  printer 
services  are  programmed. 

In  Figure  16,  Printer  Process  only  requires  the 
use  of  eventcounts  (since  it  does  not  alter  the  data  in  the 
input  buffer).  It  only  needs  to  know  when  to  begin 
transferring  the  data  and  to  signal  that  the  buffer  is  free 
upon  completion  of  the  transfer.  Thus  Printer  Process  only 
uses  two  eventcounts,  FULI  and  FMPTT  corresponding  to  the 
buffer's  containing  data  from  a  process  (FULI)  and  its  being 
emptied  by  Printer  Process  (EMPTY).  Thus  Printer  Process 
performs  an  Await  operation  on  FULL  and  waits  for  an  input 
process  to  give  it  some  data.  When  a   process   performs   an 
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Advance  on  FULL,  Printer  Process  will  "be  awakened  to  output 
it.  When  Printer  Process  finishes  outputting  the  data,  it 
will  perform  an  Advance  on  the  eventcount  EMPTY  and  loop 
tack  to  the  AWAIT. 

The  other  processes.  Figure  25,  are  to  use  the 
same  eventcounts,  performing  Awaits  on  the  eventcounts  EMPTY 
(waiting  for  the  buffer  to  become  available^  and  FUII 
(signalling  Printer  Process  that  there  is  data  to  print 
out).  Fowever,  the  awaited  value  is  derived  from  a  TICKET 
operation  on  the  sequencer  TURN.  Note  that  each  of  these 
processes  will  perform  TICKET  operations  on  the  same 
sequencer  (TURN)  and  so  will  all  receive'  unique  awaited 
values  ("turns",  as  in  taking  a  number  from  a  ticket  machine 
at  a  department  store,  [13])  for  the  buffer.  These  TICKET 
operations  will  return  a  unique  value  for  the  sequencer 
every  time  it  is  called  irrespective  of  which  process  calls 
TICKET  (provided  the  same  sequencer  is  used  as  the 
argument).  Then  the  processes  simply  wait  for  their  "turns" 
to  come  up.  Since  each  process  will  wait  for  its  "turn", 
there  will  only  be  one  process  writing  into  the  buffer  at  a 
t ime  . 

This  example  demonstrates  the  use  of  sequencers 
in  mutual  exclusion  problems.  As  can  be  seen,  the  use  of 
sequencers  provides  a  very  simple  way  to  mediate  access  to 
shared  resources,  particularly  useful  when  the  number  of 
processes  involved  is  not  known  in  advance  or  may  change. 


D.   THE  OPERATING  SYSTEM  GATE 

Somehow  there  must  exist  a  linkage  "between  the  user 
processes  and  the  operating  system  to  use  the  functions 
outlined  in  the  preceeding  paragraphs.  This  is  provided  ty 
linking  to  each  user  process  one  operating  system  module 
known  as  a  GATE.  The  GATE  contains  the  Putlfc  declarations 
for  the  synchronization  procedures  which  the  user  may 
access.  The  GATE,  then,  allows  the  user  to  call  operating 
system  procedures  in  exactly  the  same  way  that  any  EXTERNAL 
procedure  would  be  called.  The  advantage  is  that  only  the 
GATE  (which  is  very  small)  must  be  linked  and  loaded  with 
each  user  process,  not  the  entire  operating  system. 
Additionally,  during  system  generation  [16],  the  Gate  is 
located  (PL/M  terminology  for  the  assignment  of  absolute 
addresses)  in  exactly  the  same  place  in  memorv  for  all  of 
the  processes.  The  result  is  that  the  Gate  segments  loaded 
in  with  each  process  will  be  overlayed.  Thus  all  of  the 
processes  on  a  single  microcomputer  will  share  the  same  copy 

of  the  Gate  code.  This   minimizes   the   amount   of   physical 
memory  used  by  the  Gate. 

Figure  26  tabulates  the  required  format  for  all  of  the 
external  procedure  declarations  that  must  be  included  in 
each  user  module  making  use  of  operating  system  functions. 
Note  that  only  the  functions  actually  used  need  to  be 
declared  . 
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Creating  an  Eventcount: 

create$evc:  procedure (eve nt count )  external? 

declare  eve nt count  pointer; 
end; 

Creating  a  Sequencer: 

create<?seo:  procedure ( sequencer )  external; 

declare  sequencer  pointer,' 
end; 

The  Advance  Operation: 

advance:  procedure (eventcount )  external; 

declare  eventcount  pointer; 
end; 

The  Await  Operation: 

AWAIT:  PROCEDURE (EVENTCOUNT, VALUE)  EXTERNAL; 
DECLARE  EVENTCOUNT   POINTER, 

VALUE  word; 
end; 

The  Ticket  Operation: 

TICKET:  PROCEDURE (SEQUENCER )  BYTE  EXTERNAL? 

DECLARE  SEQUENCER  POINTER; 
END; 

The  Read  Operation: 

read:  procedure (eventcount)  bite  external? 

declare  eventcount  pointer; 
end; 


KERNEL  CALL  EXTERNAL  PROCEDURE  DECLARATIONS 

Figure  26 
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E.   SHARED  PROGRAM  CODE 

Processes  can  "be  made  to  share  code  as  long  as  they  are 
all  loaded  on  the  same  microcomputer  and  the  shared  modules 
all  have  the  'REENTRANT'  attribute.  This  places  all  variable 
storage  on  the  stack  so  that  there  is  no  confusion  when  two 
processes  try  to  invoke  the  module  at  the  same  time. 

Because  the  system  is  "bus-oriented  (all  of  the 
microcomputers  share  a  single  system  busK  code  sharing 
should  not  usually  he  forced  for  processes  which  reside  in 
different  microcomputers.  This  requires  access  to  the  system 
bus  for  instruction  fetches  making  this  technique  less 
efficient.  Therefore,  global  sharing  of  code  is  not  not  the 
expected  convention  during  system  generation,  although  it  is 
not  prevented  outright  [16].  In  fact  the  programmer  will  not 
he  in  direct  command  as  the  system  generation  operator  will 
make  this  decision. 

One  rule  of  thumb  that  quite  often  applies  to  attempts 
at  optimization  is  that  the  memory  that  is  saved  is  paid  for 
with  a  loss  of  speed.  Quite  often  one  can  speed  execution  up 
drastically  if  he  is  not  overly  concerned  about  using 
memory. 

In  summary,  the  sharing  of  code  segments  to  save  memory 
is  a  technique  that  is  discouraged  in  this  system  if  the 
processes  which  share  them  reside  on  different 
microcomputers.  It  will  "work",  of  course,  but  has  a  very 
detrimental  effect  on  performance. 
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F.   SEARED  TATA 

Sharing  of  data  "between  processes  is  tightly-coupled  in 
that  the  data  is  not  explicitly  transmitted  from  one  process 
to  another.  Father,  data  sharing;  is  accomplished  "by  using: 
shared  PL/M  data  segments.  These  shared  data  segments  can 
reside  in  global  memory  where  they  are  directly  accessible 
to  the  processes  concerned. 

FI/M  allows  one  to  develop  programs  modularly  ty 
providing  data  declarations  with  PUBLIC  and  EXTERNA! 
attributes.  When  the  modules  are  linked,  all  of  the  declared 
variables  (such  as  byte,  word  and  pointer  quantities, 
arrays,  structures,  etc.)  are  collected  into  a  single  data 
segment  for  the  program.  Thus  PI/M-S6  expects  that  each 
program  will  have  its  own  local  data  segment. 

In  modules  where  a  variable  is  declared  with  the 
EXTERNAL  attribute,  it  is  understood  that  the  variable  may 
actually  reside  in  a  non-local  data  segment.  The  intention 
is  that  eventually,  when  all  of  these  modules  are  linked 
together  into  one  program  the  PUBLIC  and  EXTERNAL  references 
will  be  resolved. 

Frocesses  ,  though  are  not  linked  together.  Tney  are 
altogether  independent  PL/M  programs.  However,  one  can  share 
data  in  much  the  same  way  as  the  modules  in  a  single  ?L/iv' 
program  by  declaring  all  shared  data  in  the  processes  with 
the  EXTERNAL  attribute.  Thus  each  process  will  be  aware  of 
the   existence   of   a  separate  data  segment.  The  shared  data 
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sea-merit  is  then  separately  created  as  a  FI/M  module 
containing  only  shared  data  declared  with  the  PUBLIC 
attribute  —  no  local  data  or  code  is  ever  included.  This 
module  is  then  compiled  separately  and  linked  to  each  of  the 
processes  sharing  the  data  as  if  it  were  simply  another 
program  module.  The  only  difference  is  that  this  module  will 
only  have  a  meaningful  data  segment.  The  code  segment  will 
"be  empty. 

It  must  "be  emphasized  that  such  data  segments  are  the 
only  means  of  communication  "between  processes.  In 
particular,  a  reference  to  an  absolute  address  (including 
constant  or  computed  pointer  values)  is  NEVE1  allowed.  To  do 
so  will  destroy  the  integrity  of  this  operating  system- 
design. 

G.   PRIVILEGED  INSTRUCTIONS 

Because  the  operating  system  controls  the  physical 
resources  of  the  system,  certain  instructions  which  are 
valid  in  either  the  high  level  language  PL/M  or  the  £££5 
assembly  language  ASM-36  may  not  be  used.  The  reason  for 
this  is  that  their  use  will  interfere  with  the  correct 
operation  of  the  system. 

1.  Interrupt  Masking 

The  operating  system  uses  the  interrupt  structure  of 
the  system  for  its  own  purposes.  Because  of  this,  the  user 
must  never,  repeat  NEVE? ,  mask:  interrupts  using  the  assembly 
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lang-ua^e   CLI/STI  instructions  or  the  PL/M-86  riSi>BLE/"SN.AEIE 
instructions . 

The  nperating  system  uses  interrupts  system-wide 
during  normal  operation  and  requires  that  interrupts  he 
unmasked  at  all  times  while  user  processes  are  executing. 

This  is  not  to  he  confused  with  the  use  of  interrupt 
handler  routines  which  are  required  for  certain  software 
packages,  notahly  the  PL/M-86  real  numher  library  routines. 
These  will  not  interfere  with  system  operation. 

2.   Input/Output  Operations 

Direct  access  to  Input/Output  facilities  is  also 
the  purview  of  the  operating  system.  Thus  the  user  is  also 
prohibited  from  using  the  PL/M  and  ASM-36  I/O  instructions. 
Instead,  a  system  service  is  provided  to  perform  I/O 
functions  for  the  user. 
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APPENDIX  E  -  KERNEL  MODULES 


This  section  contains  the  detail  'pseudo-code 
for  the  kernel  modules.   These  have  not  been 
fully  tested  and  should  only  he  considered  an 
aid  to  understanding  and  not  final  code. 


/*  TEE  INNER  TRAFFIC  CONTROLLER  */ 

/*f«  »•#  «v  **»  «*#  ••*  *•*  »**  ***  *>*  *•*  ***  »**»*•  »t*  »i»  .•*  *»»  **«  »i*  »»*  %*»  »•*  »•*  .'.  »■-  «'*  »'*»>»  »'»  *».  »•*  „■*  »»*  «*•  »»#  *■-  »»*  *»»  »>.  ***  »■.  •**  »**>  »*«  »•*  *»*  »**  »**  *'•  »*»  ***  *••  %•-  **>  »•*  »»*  »•#  / 
*,»  »,■•  -,••  *|«  *■,»  *,•  »|»  *|*  »(»  »,»  »4»  *,%  »,»»,%  *t*  *|«  *|*  *,*  »,»  »t-  »,-  *,»  •,»  #|*  »(*  *|«  *(*  #,-  *t»  «■,»  *■,.  #|*  »b»  #,»  »,»  »^-  *|*  -,«  *,»  »|«  *,»  "•,«  -,»  «|*  #a*  »,»  #|«  *,»  *,»  ',»  »,»  *,»  *(•  •,*  *|»  ',»  *4*  '(-   / 

/■j,  -v  «J-  ■.'-  v*-  %'-  ^*-  V*  V*  *''*'"*'  *»-y-  o*  >•-  ^  •»'-  ..*,  ■,'-  J*  *J**J*  *»*.  *.»-*  ->'  V-  **#»**  "*'  "•'  -'-  V-  »**  V*  V'  »>>s'*  5*p  «■**  •■'-  *'-  «**  ■»»-  -V  ■»'-  -i-  -J-  u,vi-  -''  »•-  y-  s1'  »*-  jfe  i4  aS*  / 
*r*  i»  *r»  i*  •*!*  *»*  *r*  n"  *r  "i^n*  *r»  *r*n»  *v*  n*  n**i*  *»■*  i*  *i*^i*  *»*  "i*  *i**i*  *i*  ******  t*  "i*  ***  t*  *i*  n*  v  •v*V'  *i*  T*  *»*  *j*  ***  *i*  *i*  *f*  *p  *p  'i**!*  *i*  *r*  *i*  n*  *r*  *'*  *p  n"  / 

/*  VIRTUAL  PROCESSOR  SCHEDULER  */ 

-r  i*  *»*  -t»  ^*  *v»  i*  *r  n*  ~ir  n*  t*p  i|»7t  n*5?  *•*  -i*  ic  *i*  *i*  i*  n>  *i*  *!"•  *r  t*  -v  *r  -v  ^  'i6  *»*  -i*  *!*•  *r  V  n*  'i"  5i*  *i*  *i*  *r  *r  -r  "i*  *r  *r  n5  n>  *»"  "i*  't*  *»*  nf*  / 

;  External  PL/M-66  procedures  called  "by  this  module 
E7TRN  GETWORK:  FAR, 
RUNTHISVP:  FAR, 
RDTTHISVF:  FAR, 
LOCEVPM:  FAR, 
UN10CKVFM:  FAR 

SCHEDULER  SEGMENT 

PUBLIC  VPSCHSDULER 

VPSCHEDULER  PROC  FAR 

ASSUME  CS: SCHEDULER 
ASSUME  DS  .'NOTHING 
ASSUME  SSrNOTHlNG 
ASSUME  ES-.NOTHING 

Entry  point  for  a  call  to  VpScheduler 
Establish  activation  record,  save  registers  that 
VpScheduler  will  use. 

PUSH  DS 

*>USH  AX 

PUSH  CX 

PUSH  PP 

CALL  L0CE7PM 

CALL  RDTTHISVF 
MOV  BP.SP 
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MOV   CX,0R        J      0H      indicates   no rmal    return 

;  Entry  point  for  a  preempt  interrupt.   Reached  "by  a  jumD 
J    from  ITC_PREEMPT_FANDL2R  procedure. 

INT_ENTRY:   PUSH  CX 

CALL  GET  WORK  ',    Returns  new  "DSR"  in  the 

J  AX  register 
POF  CX 

Swap  virtual  processors.   This  is  accomplished  "by  saving 
the  SP  and  2P  registers  in  known  locations  at  the  "base 
of  the  stack  along  with  the  VpScheduler  return  type 
flag.   The  process  hound  to  the  selected  virtual 
is  accessible  via  the  address  space  descriptor, 
the  SS  register  value. 


MOV 

SS :WORD 

PTR 

£,SP 

MOV 

SSrWORD 

PTR 

2,BP 

MOV 

SSrWORD 

PTR 

4,CX 

• 

> 

MQV 

SS,  AX 

• 

t 

Return  type  flag 

New  address  space  desc. 

;  Swap  is  complete  at  this  point  since  the  SS  register 
t  now  holds  the  new  stack  segment  value 

MOV  SP,SS:W0RD  PTR  0 

MOV  LP, SS: WORD  PTR  2 

PUSH  AX 

CALL  RUNTHISVP 

MOV  CX,SS:W0RP  PTR  4 

J    Check  VpScheduler  return  type  flag  to  determine  the  type 
J      of  return  required  for  the  process. 

CMP  CX,77F    ;  Return  type  flat  =  Interrupt? 

JNE  NOFM_RET  ;  If  not,  do  a  normal  return 

JMP  INT  RET  t    If  so,  do  an  interrupt  return 

N0RM_RET:   CALL  UNLOCKVPM 

POP  B? 

POP  CX 

POP  AX 

POP  DS 

RET 

VPSCHEDULER  EN LP 
ITC_PREEMFT_FANPLER  PROC  FAR 

ASSUME  CS  .-SCHEDULER 


1£6 


ASSUME  ISrNOTEING 
ASSUME  SSrNOTHING 
ASSUME  ES: NOTHING 

INT_VEC:   CLI 
PUSH  ES 
PUSH  DS 
PUSH  AX 
PUSH  CX 
PUSH  DX 
PUSH  II 
PUSH  SI 
PUSH  DI 
CALL  LOCKVPM 
CALL  RDYTHISVP 
JMP  INT  ENTRY 
INT  RET:   CALL  UNLOCKVPM 

CALL  CEECKPREEMPT 

POP  CI 

POP  SI 

POP  BX 

POP  DX 

POP  CX 

POP  AX 

POP  DS 

POP  ES 

IRET 

ITC_PRESMFT_HANDLSR  ENDF 

SCHEDULER  ENDS 


/  ***  ***  »**  »•*  »•*  **»  *'*  »'*  **»  »•*  *»*  »»#  %f»  *•*  •**  **-  *•»  «'.*.»*  <J.  «'«  »•»  »•*  »•»  *»*  »•*  ***  »'*  *•*  *»»  »•«  »»-  »•*  »•-  %i«  »»*  «t»  »*•  »»»  »♦*  «••  »'»  »'*  «'*  *»#  v'-  «**  »»*  »*»  «'*  »»»  «*•  -I.  ***  »'»  %'»  *•-  »'»  / 

/*     Virtual  Processor  Scheduler  Internal  Modules       */ 

/*•*  »•*  »**  *•*  *•»  »>»  %•*  »•#  »**  >»*  »**  »•*  *•*  »»*  »•*  »•»  »**  **»  .<*  ••»  *•#  »•<•  »•»  »*»  »*»  »**  »**  *f»  ***  *'*  ***  »'*  •*•  *•*  »**  ***  *•*  *'*  *'»  »**  *'*  »**  »•*  ***  »**  »**  ***  ***  »**  ***  »•*  *•*  *'*  »•*  ***  »•*  »•*  *•»  / 
»4»  *|*  *|»  *,*  »!»  »j»  ^^  »|*  *|»  »,•  »(*  ##»  »(»  *,»  »(»  *l»  »|»  »(»  »,»  »(»  *,»  »t>  »(»  *(»  *|»  »(»  *,»  »,»  #^  *(»  »»*  »(»  *l*  »|»  *(»  *|»  »j*  *(»  *|%  #|»  »|»  «4*  «|*  *»*  *|»  #|»  »|»  •■,*  #|»  *#»  r,»  •»,«  »j%  »»*  »!»  »«»  *4»  *j»   / 

/*   Externally  Defined  Variable  Declarations  */ 

DECLARE  VPM(l)  STRUCTURE 

(VP$STATE  BYTE, 

VP$PRIORITT  BYTE, 

SVCSAW$ID  BYTE, 

EVC£AW$VALUE  WORD, 

SS$REG  WORD, 

FE$PEND  EYTE)  EXTERNAL; 

DECLARE  VPM$LOCK  EYTE  EXTERNAL; 
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DECLARE (CPU$NUMBER,VP$S TART, VPSENB, VPS s?ER$ CPU ^ 

3YTE  EXTERNAL; 

DECLARE  IDLESDBR  WORD  EXTERNAL; 

DECLARE  CPU$INT$VECT0R(16)  BYTE  EXTERNAL; 

/*    Literal  constants  */ 

DECLARE  FALSE  LITERALLY  '0  ' , 

READY  LITERALLY  'l', 

RUNNING  LITERALLY  '3', 

WAITING  LITERALLY  '7', 

IDLE  LITERALLY  '15', 

TRUE  LITERALLY  '113'; 

/*    External  Procedure  Declarations  */ 

tc$pe$handler:  procedure  external; 
end; 


/*     GETWORK  Procedure  */ 

/* */ 

/*  Function  call.   Searches  the  Virtual  Processor  Map  */ 

/*  the  highest  priority  runnable  virtual  processor    */ 

/*  (state  is  either  reaDy  or  idle  with  the  Preempt    */ 

/*  Pending  Flag  set).   Returns  the  DBR  value  (SS      */ 

/*  Register  value)  of  the  hound  process  in  the  Ax     */ 

/*  Register.  */ 

/«)*  *'#  *•*  -•*  »•#  *»*  %*»  »*-  »•»  »t*«t«  «i*  »'»»#,  s<-  *■«*.'-  „>.,  .'.  %t#  v*  •■•  ***  *'*  »•*»*#  »»•  *»*»»•  »•»  »'»  »*'  »*-  *'-«.'»  v*>  »•*  »•*  ±i*  -'-  »»*  »'-  -u  «JU  %**  »**  -'-  %*'  *■'-  "'r  -'*  *'•*  *'*  •>'-  *■*-  *'*  -'-  *"-  i 
*,*  »#*  »4»  »4»  -,»  *,«  »,•  *j»  «,«  »,»  »,»  »,»  »,»•  #,»  Wg*  r,-  *(»  »!*  »,»  *,»  ?,«  *»»  *,»  »j»  »,%  *|»  #|*  »,»  *#%  *|»  *,*  *t»  *,»  *,»  »t*  *,»  *•,»  »»»  »p  *|*  »(■*  »|*  *|»  *i-»  •'i*  *,»  »|»  *|*  *|»  "I*  •»(•»  *|*  *|»  »i»  +(•   *(*  »»<»  *|»   / 

GETVCRT:  PROCEDURE  WORD  REENTRANT  PUBLIC; 

DECLARE  (PRI,I)      BYTE; 
DECLARE  SELECTED$DBR  WORD; 

/*  Beg-in  search  of  the  Virtual  Processor  Map  using  the  */ 
/*  priorities.  Initially  set  to  the  lowest  possible.  */ 
PRI  =  255? 

DO  /*  Search  Virtual  Processor  Map  for  the  highest      */ 
/*  priority  ready  virtual  processor  to  run.  */ 

I  =  VPSSTART  TO  VP^ENDJ 

IE  /*  The  virtual  processor  can  he  selected,  it  is   */ 
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/*  is  either  the  ready  state,  or  the  idle  state   */ 
/*  with  a  virtual  preempt  pending.  */ 

((VPM(I).VPSPRIORITY  <  FRI)  AND 

(VFM(I).VP$STATE  =  READY  OR 

(VPM(I).V?$STATE  =  IDLE  AND 

VPM(I).FEsPEND  =  TRUE)))  THEN 

DO»  /*  Select  the  virtual  processor.  */ 
SELECTED$BBR  =  VPM  ( I )  .SS$REG  ', 

PRI  =  vfm(i).vpspriority; 

END;  /*  Do.  Select  the  virtual  processor.  */ 

END;  /*  DO  loop  search  of  the  Virtual  Processor  Map.  */ 

/*  Return  the  SS^REG  value  of  the  selected  virtual        */ 
/*  processor  in  the  AX  (Accumulator)  Register. 
RETURN  SEIECTED$DBR; 

END;  /*  GETWORK  Procedure.  */ 

/  *ft  ^c  sff  5?*  i?;  A  afe  s^  !&  it  it  at  2!*  sk  *t  »V  ^t  4s  2**  &  s&  **f  &  ^  A  rfs  *V  ***  ***  ?*e  **•  a*-  *  *'*  ■&  V'  **-  ***  *•»  ***  *••  **-  *"*  *•*  *"»  *■  •*■  %**  *ju  **-*»*  v*  y*  a*  »•**»*  »*•    y 

/*     RUNTEISVP  Procedure  */ 

/* */ 

/*  Sets    the    selected   virtual    processor    to    running.        */ 

/*  Searches    the   Virtual   Processor   Map   with    the  */ 

/*  process's    SEITCTED$BBR.  */ 

/*'*  *■*•*  ***  **-  **-  ***  y*  »•*  «J-  *•-  *•*  JU  JU  V'  V*  *»-»  *JU  ***  «*>  y»  *».»  JU  y«  y«  *■-  y  ,  O*  %' *  y*  ***  •-**  ***  JU  *•>  y*  «■*  *U  *JL>  ***  y«  y*  *»»  y„  »■*>  -J*  *-'-  •**  v ',  JU  «■<•  OL,  »'-  »'*  ** -  »<-  -J-  *i»       .- 
*c  i*  "i*  *i*  t  *i*  rfr  *«*  'i*  *i»*i*  *r  *i**r*  'r  *i*  *r  "P  w  "v  ****  *?  *i*  *i***r  *c  t*?  *v  *i*  *i*  *r  *iwr>  *»**  »r»n*  *•"*  *>*  *P  *•■•  '»*  **"  *»*  v  *r*  *i»  ******  *i-  n*  *t*  *i*  *"**  ''*  '•*  / 

runteisvp:  procedure(vfidbr)  reentrant  public* 
declare  vp^dbr  word, 
vp    byte; 

vf  =  vf$end; 

DC  VEILS  /*  Look  for  the  VP  with  this  SS$REG  value.  */ 
(VPM(VP).SS$REG  <>  VP$DBR); 

VF  =  VF  -  i; 

END;  /*  Do  While  */ 

VFM(VP).VP$STATE  =  RUNNING; 

R^TU^N  * 
END;    /*   RUNTEISVP   Procedure.    */ 

/•fctrf  *.'^  •#>   -J*  %\r-  «i#  «Jj.  «ltf  fc'*    -J  J  *i-   %X-   «JU*I«   «J*  «|«  >»,  «|*  OU  «J*  »''  «!•  «J-   *J-»   "V1*  **>   •"'"    ■>■•*  » ''    »'*■  •*■*   *•"   »'■»   ^#  **-   --''   «■'*  »'*   ■»*-   •>'■•   «'*  »'»   **-   ■"■'*  «1#  »'  -  *•*  »' '   ■*'  -  -■'-   ■*'  *   «■'-   »'  -   • '  '   *  '*    »'  -   »'  -        / 
"t*  *i*  *<*  *i*  'i*  *i*  "4*  i*  *i*  *!****•  *i*  *i**t^  *»»  *t*  *i*  '4^*1**  *•*  *<**  ******  *r*  *i*^*  *r*  *r*'i*  nc**«*  *i**  *•*  "i**  •**  *•  *p  *i*  *i*  *t*  *»*  *i*  'i**  i-*  *f*  "i%  *i*  *t*  *i*  *•■*  *»*  *4*  "i"  *i*  *i*  nr*  *i*  / 

/*     RDYTEISVF  Procedure  */ 
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/* _ */ 

/*     Sets  the  currently  running  virtual  processor's    */ 
/*     state  to  ready.  */ 

/3ft5*!Sft  3*t  s!!  ;'i  sit  ;'s;*;  ;*J3*ii'r  *'*:';  ;"s  ;'**'f  V* »'-»»-  »**  *»-»•-  »•-  *•*%»»  *»*  *»-%»*  jujuvu  »**%•-  ^*  jujuju  »»*  «•,..'»  »t,  .<,»**  »i«  »>- %i..»,  «i*«i*  ju  %».»«*  %«.%»»  »**»t,    , 
*l*  "l*  *»»   *»*  *P  •»»  *l*  *l*  *»*   *«*  *l*  *»*   *t+  *»*  »|%   »»*  »»*  *p  *|*  I*  »»*  *p  *»■•  #|*  •»»  »j»  »p   »p  »,»   »p  »|»   #|1  «(%  *i*  »p  #p   -p  #,S   *p  *g*   »p  »p  »p  rp   *(*   »p  *p  »p   *p  *p  #,»   »p  »p  *p  »p   »p  *p      J 

rdtthisvp:  procedure  reentrant  public* 
vpm(itc$r2t?vp).vp$state  =  ready; 
return; 

END?  /*  RDTTHISVP  Procedure  */ 

/***  iV.  ***  V*  ***  »**  ***  •**  *•*  ****'*  »**  JU»»#  *•*  »»»  *»»  »»»»•*  %i«  J«  »**  **»*•«  »•»  -.'■>   »•*  .•-«■»  «i*  «*«  »•-  ***  »ji»  WU  JU  y-  J*  JU  J*  s'*  -C  »'-  *»,  JU  JU  »,»*  J-  JU  JU  J*  J*  ■*»*  J*  »**  *'*  ***  y 
»l*  *|*  *»"  »(•  *»*  *»*  *|*  *p  »p  #|»  »(*  *p  *p  *p>  *p  ^|*  *(*  *p  »p  *p  *%*   *p  *(•  »|»  ^*  »(•  *p  »p  *^  #|*  *p  »p  #p  »p  *|^  »|»  »p  *-p  *p  *(*  0f*   ^p  »p  *|»  *|*  *p  *^»  *|»  *p  *|»  »p  »p  *p  #p  *^»  »|*  ^»   / 

/*     LOCKVPM  Procedure  */ 

/* */ 

/*     locks  the  Virtual  Processor  Map.  */ 

»,*  *tv  *^  »|*  *|*  *|*  •"!*  *|»  *#*  *p  *i»  »|»  *(* *t»  *i»  »»*  *g»  »|* *t»  *^%  *j»  *|»  »,•*  *p  *fr  ^|*  »;»  *|*  *^«  *fr  *f»  * ,-.  «n»  *p  *,»  *|»  »t»  J|%  *,*  »t*  *|*  *,»  *-, »  *|»  *■,%  *|»  -,h  #j%  *,*  *,*  *■,»  /,.  ^, -  *j»  (|«  •»,»  ^r,-   / 

LOCKVPM:  PROCEDURE  REENTRANT  PUBLIC; 

/*  PL/M-S6    built-in    spin-lock  procedure.    */ 

do  veils  loc£set(0vpm?lockf119); 

end; 

return; 

END;  /*  LOCKVPM  Procedure.  */ 

/*V  **-  -i'  *Ar  «(«  JU  JU  >JL«  ^-  «K#  J-  «JU  «0*l«  -J*  -,'^  **-  <JU  »C  »'*  »t-  %'-  -U  VU  <JU  aJM  -'-  «J-  ~l-    *'»  O.  »U  J*  O*  «1»  »'-  O*  JU  -J^  JU  »'*  •.'»  »'-  -*-  «*«  «-'-  •.'-  «'-  ^'.  .'-  »'»  «J*  «JU  »■-  »•-  A  J*      / 
't*   *^  ^f»   *|*  T»  #^»  *|»   *(»  •!»    »(•  *f*  *J*    *(»*|*    »g»    /-,-v  +%t   *f»  r(+  *(>  *t»  #|^   *j*   *|*    *|»  *|»   *l»    'p  ',»    ^(»  *j%   »,»   »|*   *p  *,>    Wj*  *(*  ^*    •>,■•    »|*    »(»  »f»    »,»  *|*   *|*    *,»  *,*  *(%  *,»  ^p   #|*    f,«   *p   *j.  *p   *p  ^p        / 

/*     UNLOCKVPM  Procedure  */ 

/* */ 

/*     Unlocks  the  Virtual  Processor  Map.  */ 

/»'*  *'*  »'*  •*»  »'*  **«  **»  h'-  *'»  ***»*»  »'»  -  *  »»»  »'rf  %'.  »*.  •.*'  »»*  «'v  fc*.  +'r   »'*  <.'-  «(«  »■#  **•  fc'»  »'»  v*»  «'«  s'»  . '*  »■»  *'-  «■•  »'»  »'>  «■*  «*•  h<«  .'.  »'#  »'»  ■»'»  *'-  »'*  *>a  »'-  v'*  •'•  *'»  »**  »*'  »'.  »'-  »'»    / 
*,«  »t»  *|«  ■•,»  »,»  ',«  *|«  ',-  *|>  »,-  *t-  •■,«  *,»*,.  *|«  #(.  -,.  »,»  #,»  -p  .,-  *,■.  »t»  *,•  «(i  »,■•  ',-  »,»  »,»  *t-   »,•■  ',-  »t-  #,»  -,   .,»  *|*  -(.  »|*  #|«  «(*  »(.  »¥»  #|*  wgm   *|«  *,>  ^p  #p  »p  »,»  *,-  »,.  rp  ^,«  #p  #,»   / 

unlockvpm:  procedure  reentrant  public; 
vpmslock  =  0; 
return; 

END;  /*  UNLOCKVPM  Procedure.  */ 

/%»,-*-.  *i*  «t*  «f«  »•,  »i*  . ■-  »'*  v'*  *',  fci,  **#%*«  »•-  »•-  »».  *•-*»*  *>-  **«  »*-  -■*  *•-  %'.  »*#  »**  »»»»■*  •■•  «**  -'-  *'-  %*•  *'-  »'-  -.'»*»-  «■»  «■*  *.*.  .'.  «••  -'-  *■-  *'*»•*  »*•  *•* » '■-  »**  «■-  *•-  «*•  -■  •  *'•  -■  -  / 
*,*  *j»  »#»  »p^  #p  »p  *|%  #p  *p  *,*  «|«  *p  »t»  »p  »p  *p  »,  .  *(«  *p  »!»  »,*  *p  *4*  *p  »p  *j*  »p  »!»  »|%  #p  *p  »|»  •(»  »i*  »|»  *p  »|»  »»»  »»*  *p  »p  »4»  »!*  »|»  »(»  *p  »p  *|»  *p  *|*  *»*  *t»  »(»  *i*  »|»  *t*   '»*   *' 

/*      FDVFSINT  Procedure  */ 

/* y 

/*      Generates  a  hardware  preempt  interrupt.  */ 

/*■«  J-  «f«  •,!•  JU  «J-  JU  *»*  *f*  *J-  »'-  »l-  «•#«!«  »•*  *t-  JU  o.  -'-  •*»  JU  *»*  JU  *«*  JV  *•-  JU  JUJU  *»-  JU  »*-  *»»  J1*  *»*  »•-  *'*  »'*  »»<  *'*  *•-  *•*  »'*  *•-  »»*  *•#  *.*-  *«*  »'-  *•*  *U  »»*  *»j  »•;  J*  »•-  *•*      ^ 
*p  »p  *p  »p  ?p  ,  p  *p  *>p  ^p  *.p  »p  #>p  *p  »p  *-p  »,»  ^p  *p  *j»  r|*  #j»  *t*  *i*  'I*  ***  *i*  '\~*  *f*  *»*  'i*  *i*  'i*  'i*  *i*  *i*  *%■*  *i*  *•*  *l*  *»*  *P  *"i*  *4*  *r*  'i'*  *i*  *i*  *l*  *<*  Hr  *<*  *.■*  "I*  ***  *»*  *i*  *»*    / 

HDWR5INT:  PROCEDURE (CPU)  REENTRANT  PUBLIC; 
riCLARE  CPU    PYTE, 
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FORTA  LITERALLY  '0C8H'j 

OUTPUT (FORTA)  =  CPU$INT$V2CT0R  (CPU)  ; 

RETURN 
END;  /*  EDWB$INT  Procedure.  */ 

/^z  **x  ^;  y '  ;*'  ^  *'*  "^  •*•  **-  *'-  *■'-  *,>  *'*  *•*  ■»' - "'-  °- »*-  *'-  »•-  ***  •>•*  ***  *■'-  *>-  -''  **-  **>  -'-  *^-  -J-  »*-  *•-  *•-  **-  «*•»*-  %•*  »**  *•*  *'-  *»* »'.  *.'*  -*-  rfu  »<-  »»«.  »j-  »»*  »•* »»-  %•*  *•-  ••*  *>•  y 
*i*  *1*  •"»»  ^*  *|*  *|»  »(»  •"i*  *f    •*(»  *1*  *l»  *|*  *!"•  »»*  »»»  »(*  *J*  *f*  *t-   *|»  *|»  *j»  *i»  *§•  *)»  »!*  *■!>  *f+   »|»  *|*  *|*  *|»  *,«  *gE  *j%  »p  »»»  *,«•  *»»  »|»  *,»  »»*  *,%  *!*  »|*  »|»  »|*  »|«  »,•  *»*  *|»  #,»  rt*   #(»  »,»  *|»   / 

/*      Inner  Traffic  Controller  Interface  Modules       */ 

/afesksfeaSe  sSeaSsaSs  afie  afe  A  ;*t  &  ysste  y*  sb  s!s  sf*  s**  v-  *»#*•-**•*•-  **-  v-  «ju  »i,  *i*  *i-  u#  *i»  o-  «ju  *i*  5u  »»*  *•*  *u  »i„  *»*  *•*  »t,  u-  *»,  *»,  y-  *•*  v-  ***  **- »'-  *•*  **-  <**  •»-*••  > 


•i»  *»*  *••  »•*  »#■•  ».*  *i*  '»■»  »i*  -,»  *i*  *f  *.»*»*  *i*  *»«  »»*  -v  -«»  *i*  *,»  *i»  *%%  *v  »i*  *i*  *»*  »»-  *■*  »i»  5(*  *r  *F  'i*  i»ttti»t  3r  *i*  i*  ^t*  ^  *i*  *r»  f»  i*  i*  n*  i*  *t«  *i*  *p  'r»  *»*  / 

/*     IDLE$?P  Procedure  */ 

/* */ 

/*  Sets  the  state  of  the  virtual  processor  now  */ 
/*  running  to  idle,  "binds  the  "idle  DBR",  sets  a  */ 
/*     high  priority  and  calls  Vp_Scheduler.  */ 

/  *t  *  j,  ,«/  »i.  ^  j.  ,«,  j,  j.  j.  .',  .',  ^  ^  »u  j,  »i,  j,  j,  j>  j,  ,i,  ^,  j,  j*  j.  -'**'z  *■*  if-  s&  IS  A  2?r  afe  i!c  ic  dfi  9&  ***  -1*  sic  si  sb  ***  •*•  afe  i'  afe  A  5ir  s!r  A  5b  21*  5?r    y 
/  *i*  ^*  *i*  *P  *«*  '»*  nr  *i*  *^*  "#•  *i»  *»*  *n  *r  -i*  *p  *r  *»»  ^i*  *r  n*  *!*  **»  T1  *** *i*  ***  i* *»*  *i*  *»*  'i*  *i*  *p  n*  n*  *»*  nr  *i*  *i*  *i»  *i»  *t* *r»  n*  »»»  n-  n*  *i- *i+  *i»  i*  i*  *»*  *ir  *•*  ^*  / 

idle$vp:  procedure  reentrant  pu3licj 

declare  vp$t0$ille  eytej 

7pst0sidle  =  itc$ret$7pj 
vpk(vp$t0sille).vpsstate  =  idle? 
vpm(vpito$idle).vp$priority  =  10; 
vpm(vfst0sidle).sssreg  =  idle^dehj 
call  v"°?ceeduler; 

return; 

END;  /*  IDLE$?P  Procedure.  */ 

/%!<•  ***  4»  ***  %f*  «'-'  «-**•  »*-  *l«  JU  «J«  *A*  v»-  ^i-  %i*  Jh  «*'  %**  «■«  *f>  **■•  •-**  V*  V*  *'-  *'-  »•»  *J*  *•■»  -*-  *-'■*  *'*  *'-  "*-  ***  *'*  ***  V'  *■'*  *^  J*  *■*'  '",-  V*  *'*  "'*  -''  V'  »*-  »'*  *■'*  •* *  v''  *■*  -  »'*  -' '  **-   / 
»l»  »p»  J^  *|»  *,*  *(^  ^|*  »|>  «p  9|%  ^|»  *|»  «|«^|v  »|«  «■]»  ^f%  «p  »|»  *,»  ^«  *f*  *|»  *(*  *|»  *|*  *|*  *|»  *(*  *g*  ^i*  *|»  »^»  *i»  ^|*  »|*  ^i*^,*  rt»  *)*  »|-»  »|»  *,»  *!"•  *|*  *,*  *j»  *|»  *,••  *!»  r,»  *j»  *j^  *(«  »(*  *p  *■,%   / 

/*     ITCSLOADSVP  Procedure  */ 

/# _  _ */ 

/*  Performs  a  "Swap  Virtual  DSP." .  Binds  the  virtual  */ 
/*  processor  to  the  new  process,  updates  VPsFRIORITY  */ 
/*     and  SS$REG,  and  sets  state  to  ready.  */ 

/*•*  *•*  s'*  »**  »»»  «l«  »»»  0»  via  «*•  »<•  «**  »*.*■*  »•#  k»-  «t#  ■*'*  v'*  «*•  •<*  «'*  *'*  •.'•  »'**'*  -'•■  »'-»•-  »•*  «■«  ***  »**  »*-  ■»•»  -'*  «*«  ».»«  **•  **•  •.'»  »•*  V*  »'*  "'-  "■''  *'  *  *■'-  »*"  *■""  *■'*  *'"  "'•  »'"  *■'"  *'*  ***   / 
#,»*,»  ?(*  *,»  »,-  *,-  7(*  0j«  ♦,%  #4»  *4»  »t%  »,•«,«  -(»  *|*  *|«  *,-  »j»  »,»  #|»  »,»  *|»  »,-  *,-**,»  »,»  *(*••»-  'I*  *|»  «^»  »|»  *»*•»»  *|»  *.*  *»»  *»*  »i»  *|»  *»»  *»»  »»»  »|»  *»*  •»»  *|»  '**•»*  ••»  *l*  *l*  *l*  *»*  *•*  *|*   / 

ITCSLOADSVP:    PROCEDURE(PRI $PARM,DBR$PARM )    REENTRANT    PUBLIC? 

DECLARE  PRI$PAP.M  BYTE, 
DBR^PARM  WORD, 
L0AD$VP    BYTE; 
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/*  Identify  running  virtual  processor.  */ 
LOADSVF  =  ITC$RET$7PJ 

/*  Bind  the  virtual  processor.  */ 
VPM(L0AD$VP).7P$STATE  =  READY? 
VP(*(LOADSVP).Vp4??IORITY  =  PRISPARMJ 
V?M(LOAP$VP).SS$REG  =  DBR$PARMJ 

/*  Schedule  the  virtual  processor.  */ 
CALL  vpscfeduier; 

return; 

END;  /*  ITC$LOAD$VP  Procedure.  */ 

/J.  J;  .',  .',  .•-  vlf  J;  ,1.  hI.  O.  *<,  .U  J-  J*  J.  ,1,  ^,  ,',  J,  Jy  .I,  4I,  ,1,  J*  J.  ,1,  4I-  J,  J.  ,'.  J,  J,  O.  J*  J.  .'.  J*  s'*  vl.  J-  J,  J,  J,  ,',  J,  X  ^  ,',  O-  J.  Urn    *l  -  JU  %'-  **«  »t,  *t„  JU   / 

/*     ITCSR3T$VP  Procedure  */ 

/* */ 

/*  Function  call  which  returns  the  identity  of  the  */ 
/*  virtual  processor  which  is  now  running  od  the  */ 
/*     physical  processor.  */ 

/■*!,»  «V  «A*  «►•*  %*.»  *JU  %0  V'  »"*   "•'-»  *'■"   ■***  ***  *•*■*  ***  *'«■  *»**  ^'  ***  ***  ***  *.',«   »0   <*«  J<  »•*  •!*  »'*  *J*  »t*  » ''    i'*  OU  ••**  *Jr  >'■»  *•-  »'»    *■  '■•  «J*  %• >  «■'*  »*#  *■»  *■•*   »l*  *• »  »V   »• »  V*  *■'*■    ***   *'*  -''   -'*   *'*  ***  »*■*        / 
*|*  *l»  *i»    *|»  *i^  »|*  *i»   '(*  *J*    *1»  *l*   *|»   »,»#|»   *^»  *y+  *(»  *|»  V|>  »f%   rtt  *(»   *p.  #|%    .•,-.    rt-    *,-  *p  ^f*    *,»  #(«    »,»    »,-»    *-,»  »,»    Jy*    .(i  *,»    *-(s    -,H    »j-»  *j«    •  ,»  *|*  >|*   *,«  «■,»   *•,»     •._-•',■»    *,>    «,«   »|»  ^(»   x,»    >,  .    *,*  #■,■•        / 

ITC$RET$7P:  PROCEDURE  BYTE  REENTRANT  PUBLIC* 

/*  Search  through  the  set  of  virtual  processors  assigned  */ 
/*  to  the  phsyical  processor.  */ 

RUNNIMG$V?SID  =  VPSSTARTJ 

DO  WHILE  /*  Have  not  found  the  running  virtual  processor  */ 
(VPM(RUNNINC-$VP$ir).VP$STATE  <>  RUNNING); 

/*  Search  next  entry.  */ 
RUNNING^VPSID  =  RUNNING$VF$ID  +  1J 

END;  /*  While  loop  search  for  running  VP.   RUNNING$VP$IE  */ 
/*  points  to  the  running  virtual  processor.         */ 


/*  Return  the  identity  of  the  virtual  processor   */ 
/*  in  the  AX  (Accumulator)  Register  */ 

RETURN  RUNNING$VP$ID; 

END;  /*  ITC$RET$VF  Procedure.  */ 

/*     CFECKPREEMPT  Procedure  */ 

/* */ 
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/*  Checks  for  a  virtual  preempt  pending.  If  there  */ 
/*  is  one,  calls  the  Traffic  Controller  Preempt  */ 
/*     Handler.  */ 

*,-  *»*  *,-  *,»  p|«  -,-»  *,*  ^|*  #|*  -,^  --,»  v ,»  *■,*  *■,■»  <-, *  *f*  >,-.  .»,»  ,,»  ^«  .,«  #|*  ,,»  ,(^  ,,„  *(,  *,„  »,»  .j*  «k<»  -,,  #,■*  *.(^  ,,,  ,,.»  *(>  J^  ^  ,|%  #p  7^  «.,*  *, .  J^»  *,«.  ,,..  ^*  »,»  7^  *,*  »,-.  »,-»  *|4  #|*  ^t  «■,»  * p  »!»  / 

CFECKPREEMFT:   PROCEDURE  REENTRANT  PUBLIC- 
DECLARE   RUNNIMG$VP  BYTE,' 

/*  Find  the  identity  of  the  runnirg  virtual  processor     */ 

RUNNING^?  =  ITC$RET$VFJ 

DO  VEILS  /*  Preempt  Pending  Flag  of  the  virtual  */ 
/*  processor  is  on.  */ 

VPM(RUNNING$VP).PE$PENE  =  TPUS; 

/*  Reset  Preempt  Pending  Fla/?.  */ 
VPM(RUNNING$VP) .PERPEND  =  FALSE? 

/*  and  call  Traffic  Controller  Preempt  Handler.  */ 
CALL  tc$pesfandler; 

P.tJNNING$VP  =  ITC$RET$VF; 

END;  /*  While  loop  handling  of  the  virtual  preempt.       */ 

return; 

END;  /*  CHECKPREEMPT  Procedure.  */ 


/  »•*  ••*  »•*  J**  »*»  %»*  »**  »**  «»»  *t«  .'-  «*«  *',  j'r    <J*   «Jg  *•*  »'»  %tr   »*»  ***  »•.  .'»  »»»  *l*  »*,  .•»  «•*  »**  %»,  «(«  »»,  .'»  «l*  ,•»  »».  «f«  *f*  »**  »«»  «*<•  »<  .  «•«  »»*  »'  -  «.'..  »'.  »*»  «>«  ***  »'»  »•*  «■#  «,»,  »>,  »•»  %'»  J»*   / 

/*     ITC$SEND$PREEMPT  Procedure  */ 

/* */ 

/*  Issues  virtual  preempts  (preempt  interrupts  to  */ 

/*  virtual  processors)  by  setting  the  appropriate  */ 

/*  Preempt  Pending  Flag  in  the  Virtual  Processor  ^ap  */ 

/*  and  then  issuing  a  hardware  interrupt  if  the  */ 

/*  processor  is  on  a  different  physical  processor.  */ 

/»*»  »■*  »**  *•*  »•#  ***  »•»  »••  *»*  %■*  *»*  «*•  *•*  »■•  »•*  *»*  **.  »<*  »•*  %•• »'-  *■«  »•*  *f*  %i.  «i«  »*-  »••  »•#  *»*  »•-  «*#  »*-  *•-  »•*  **»  «•#  «••  »*»  »■*  *•»  »'>  *>« «'-  »*»  »'»  ••#  »** »'.  ••*  ♦**  »**  ***  »*#  »**  *•»  *••  ***  / 
»,»  *|»  *,»  *g»  *,»  -•,-  »(•  »,»  »#»  *!«  *,-  J,»  '|**(*  »(»  *(•  *,»  *(»  »,»  *,•  #|*  »4»  #4*  •(»  *(»  *t»  *,»  *(»»j»  *,»  »,»  #,»  *,*  »|»  »,»  »,»  v,**^  ##«  *>»  »,»  *#»  »p  *,»  »,»  *,»  »,.  »,»  »,.*,»  «,»  *(*  »|»  »,»  »(•  r,»  »,»  »,•   / 

ITCSSEND$PREEMPT:  PROCEIITRE(TGTSCPu  ,  VPSID  )  REENTRANT  PUBIlCt 

DECLARE  TGT^CP'J  VORD, 
VPSID   word; 

/*  SET  THE  PRE-EMPT  PENDING  FLAG  */ 

VPM(TGTSCPU  *  VPS^FERSCPU  +  7P$ID) .PESPENL  =  TRUE: 
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if  (tgt$cfrj  o  cpu$number)  then 
call  hdwr$int(tgt$cpu); 

return; 

END;  /*  ITCsSEND^FREEMFT  Procedure.  */ 

/*     ITC^AVAIT  Procedure  */ 

/* */ 

/*  Eventcount  synchronization  mechanism  for  use  "by  the  */ 
/*  Inner  Traffic  Controller  in  the  management  of  */ 
/*     system  resources.  */ 

/*"#»**  -**  -'.  *>«  «.<»  *•«  tfm   •>'*  %**  *'»  »'.  ***  ***  *'*  *'-  »'*  »'»  »'*  »'*  *'<•  *■'*  ***  "''  •■'»  »»#  «JU  •■'-  ***  «l«  «X»  «JL*  »**  »*'  *•*  *'-  *'-  *"-  v'*  -•»  V-*  *'*  **-  **-   •***  **»  *'*  "J*  *'*  V'  **■*  "•**  *■*'  "•'*  V*  *•*  "J*  *V  "»i*   / 
*i*  *•*  *»*  #i*  *•*  *»%  *»*  *•*  *»*  »4*  *»*  »•*  *i*  »•*  *»»  *i*  *•*  *i%  *t*  *»*  »»*  ***  »»*  *»*  *»*  i»  *i*  *i*  *(*  *i*  *■»*  'i"  *c  n*  *i*  *i*  *p  *¥*  *p  *»»  *r*  *i*  *i*  *i*  i*  n*  *»*  *p  *F  *Sc  *tt*  *»*  'i*  *i*  *i»  *i*  *P  *i*  *r*  / 

ITCiAWAIT:    PROCEDURE (EVC$ID , AVAITED^VALUE)    REENTRANT    PUBLIC  J 

DECLARE  EVC$ID        BYTE, 

AWAITED?VALUE  WORD, 

RUNNING$VP    BYTE, 

I  BYTE; 

/*  Lock  the  Virtual  Processor  Map  */ 

do  while  i0cxs2t(?vpm$l0ck,119); 
end; 

do; 

/*  Identify  the  running  virtual  processor  */ 

eunning$vp  =  itc^retivf; 

if  sys$e7csta3le(evc$id)  <  av/aited$value  then 

do; 
v?m(running$vp).vp$state  =  waiting? 
vpm(running$vp).evc$aw$id  =  evc^idj 
vpm(running$vp).evc$aws7alue  =  awaited rvalue  j 
end; 

ELSE 

v?m(running$vp).vp$state  =  ready,' 
end; 

/*  Schedule  the  virtual  processor.  •/ 
CALL  vpschedttier; 

/*  Unlock  the  Virtual  Processor  Map.  */ 

vpm$lock  =  e; 
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END?  /*  ITC$AWAIT  Procedure.  */ 

/*•-  -f'  ■>'-  -J*  -Jf  JU  »'-  *V  ^-  -.'-»•*  -•-  -V  -'"  **'  •*'   *•'-  "•'-  *,J  -''  ***  **-  •>''  **"  J-  vi-  J*  **•*!«  «.'.*  **-  »•-  JU  *<-•.'*  »»*  *t«  *i,  O*  V*  »'-  -'■»  «•"-  V*  -'•»  *■'»  *■'■•  ***  *'•*  -'•*  ***  "■'-  -'-  ***  *'~  »'*  ***  "'*  "J*  / 
*l»  1*  *i*  *|*  *j*  »|*  *|»  *|*  *j*  »|*  *|*  *[»  rj*  *|*  ^|*  »|*  *|*  »(»  *j»  *|%  #!■»  »|»  »|*  *|*  *|»  *(%  *,»  »(»  »|*  *■(*  »,»  *|*  «■,*.  *|*  »p  *,»  *i*  7,«  ?|»  ^^  *(»  *(»  *■,■»  J|*  rf*  »,»  *,»  ?p  *,»  *|»  ^|»  *,■»  »|*  ^|>  »(%  *(»  *|*  *|»  *•(*  / 

/*     ITCUDVANCS  Frocedure  */ 

/* */ 

/*     Eventcount  signalling  mechanism.   Used  by  the  Inner  */ 
/*     Traffic  Controller  in  mana^ins  resources.  */ 

/s^AsV  sfrVe  a'siis*;  i1'  afeafttab  }»***-y-»*,**»-vi**,*«JU»U5V  ***»■*  o*a,  a*  ^ui  ^,^  -a.  *»*  u~u*  *>..»■<.  *i»  *»-  v-  -<*%»-  *>*  <a,  *»•  *»*  %>-  *»-  v-*1*  »*-  ••*  »•-*»**»**•**#*»»*  %»«•    y 

/  *V  *1*  »|*  *S»  *»»  '»»  'I*  *»»  *|»  *|*  *"|»  *|*  *|*  *l*  ^p  *|*  *|*  rf(*  *("»  ^j*  *t*  ^|S  *,»  »|*  »,*  *j%  «f|»  *,<•  *!*  «■,»  J^%  *[*  *(»  »,.  *,»  *,.»  g^m  ?|»  *,-»  ?4»  *,»  J,*  *(%  ■-,»  »,^  *,»  »[•  *,*  3j»  »|»  *(»  *,»  »,»  ^.»  *,-  *j»  +i-  +f  5j»   / 

ITC$ACVANCE:  PROCEEUEE(EVC$ID)  REENTRANT  PU2IIC 
DECLARE  EVC$IC  PYTE, 
I      BYTE; 

/*  Lock  the  Virtual  Processor  Map  */ 

do  while  l0ckset(pvpm$l0ck,119); 
end; 

sys$evc$tabie(evc$id)  =  sys ^svc$table( evc^id)  +  1? 

DO  I  =  0  TO  (NRiVPS  -  i); 

IF  VPM(I).EVC$AWSID  =  EVCSID  THEN 

IF   V?M(I).EVC$AWSVAITJE   <=    SYS$EVC$TAHE(EVC$ID)    THEN 
DO  * 

VPM(I).VPSSTATE   =   READY,* 
VPM(I).EVC$AWiID   =   255J 
VPM(  I  ).EVC UPVALUE    =    2'f 
IF    (I    <   ?P$START)    OR    (I    >   VF^END)    THEN 
CALL   ErVRSlNTd/VPSSFERsCFU); 

end; 
end; 
call  vfscfeduler; 

/*  Unlock  the  Virtual  Processor  Map  */ 

vfmslock  =  0j 
return; 

END;  /*  ITCSADVANCE  Procedure.  */ 

/ou.  -»--»-  -J,  U,  ,'-  V*  +>'  *J*  -J-  -*-  -'*  *V  -''   ">'-  -J-  J-  ->!'  •*'   J*  -**  •*•  *■'•  -*-•*'--'-  *J*   -•-  J-  -'-  *U  -*-  •***  -•*  *',  »-**  -'-  -U  J>  JU  «.<-  -'-  *U  «.'*  -'-  » »-  «L>  «b  ^»-  «.'-  *»*  *'*  *»-  •*•  -J-  -J-  «'*  *'-  »»-  / 
*i*  *»■*  •**  *i*  *•*  t»  *#*  *i*  *■»*  *i*  *i*  *i*  *i*  *•*  *<•  *i*  *>'*  **"  *»■•  *r*  *<*  ***  ***  ^*  *i*  *i*  *i*  *v  i*  *y*  *t»  n*  i*  *»■*  i*  *i*  •*»*  *i*  *i^  *i*  i*  *i*  *i*  *»*  nr  *i*  i"  *r*  i*  *^*  *>*  v  *»*  '•  •  ^  t*  •  "^  / 

/*  TRAFFIC  CONTROLLER  */ 

/  vo  ^  x  ,c  x  ,i, .'.  >i,  .',  j,  j,  o,  J,  j,  j,  j.  j*  j-  ,«, ,',  ,u  j,  »'-  o-  j-  j,  a  o-  j*  *'-  j*  -a.  »»*  »»-  o-  -t^  .j,  o-  »t,  *i-  *t*  ju  »i*  v*  ••'-  %fe  -J-  ***  **-  *<*  afc  a&  *'-  s1-  si-  ***  *'-  ^r  y*  ,' 
/  'r>  *!*•  "i"  *i»  *i *  *»»  *?  h*  *i*  *<*  I5  *f  *i*  n*  1*  *i*  i*  *i*  "t'*  *i*  't*  ^*  *im  *t*  i*  *i»  "i*  ^i*  'i*  '»*  t*  *i*  'i*  -»»  n*  'i*  *r  -i*  't*  ***  *i-»  *»*  *»»  Ji*  i»  'i*  nr  "i*  *i*  *•*  t*  tt  *i%  *»*  *»*  "»*  *»*  ***  t>  / 


/*  External  Global  Data  Declarations  */ 

/. '.  -><■  %f*  x  s*-  «i«  J-  *'*  ^*-  -■-  *'-  *■»  -.'-•  -*-  »'*  ~*-  *i«  *'^  «*'  *»-  **#  V*  *-*-  ■>'-  »'-  »'*  -'-  «■'»  ■>■'»  •**-  ***  -'-  "'-»  *'*  -''  -''  -''  -**  -'"  **■•  >'-  *•''  »*'  •"''  -'-  »'*  -J*  *'*  »'-  ***  ■»'-  •»'-  *■'"  ***  *'*  ***  *'*  *'*  *''  / 
*,»  *|t  r(>  #p  *■(*  *(*  *|*  »|»  *|»  *f»*|*  •-,»  *(^  »(»  *|»  #|«.  *|*  ^|«^«  #p  *t*  ^|*  *|%  *p  *j**|*  *,«•  *|*  ^(»  *p  *,»  +(*   *,»  r,»*,*  *,>.  1*#|«  *V*  *("*  *(»  ■*,"•  *|>  »|*  *i*  '|-  *(»  "i»  *,*  *{*   '|»  »,*  *"|»  ',■*  *»»  *|*  *|*  *|*  *.*   / 
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DECLARE  AFT(l)  STRUCTURE 

(STATE  BYTE, 

AFFINITY  BYTE, 

VP$IT  BYTE, 

PRIORITY  BYTE, 

LOAD$TEREAD  BYTE, 

EVC$7ALUE$AW  WORD, 

THREAD  BYTE, 

DBR  WORD)  EXTERNA!; 

DECLARE  APT$LOCK  BYTE  EXTERNAL? 

DECLARE  FROCESSES  BYTE  EXTERNAL; 

DECLARE  L0AE$LIST(16)  BYTE  EXTERNAL? 

DECLARE  EVC$TABLE(1)  STRUCTURE 
(EVC$NAME(6)    BYTE, 
EVC$VALUE     WORD, 
APT$PTR       BYTE)  EXTERNAL; 

DECLARE  EVENTS  BYTE  EXTERNAL; 

DECLARE  SECiTABLE(l)  STRUCTURE 
(SEQ$NAME(6)    BYTE, 
SEOiVALUE     WORE)  EXTERNAL? 

DECLARE  SEQUENCERS  BYTE  EXTERNAL; 

DECLARE    (CPU$NUrBER,VP$START,VP$ENr,V?S$PER$CFU) 

BYTE  EXTERNAL; 

DECLARE  (NR$?EPS,NR$VPS)  BYTE  EXTERNAL? 

DECLARE  CPU$INT$VECT0R(16)  BYTE  EXTERNAL; 


DECLARE  PR 0$ PAR AM 

STRUCTURE 

(FLAGS 

WORD, 

CS 

WORD, 

IP 

WORD, 

ES 

WORD, 

DS 

WORD, 

AX 

WORD, 

cx 

WORD, 

rx 

WORD, 

BX 

WORD, 

SI 

WORD , 

DI 

WORD, 
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SS  WORD, 

PRIORITY    BYTE, 
AFFINITY    BYTE)  EXTERNAL; 

/*  Literal  Constant  Declarations  */ 

DECLARE  FALSE  LITERALLY  '£', 

READY  LITERALLY  'l', 

RUNNING  LITERALLY  '3', 

BLOCKED  LITERALLY  '7', 

TRUE  LITERALLY  '113', 

NOT$FOUND  LITERALLY  '255', 

NIL  LITERALLY  '255'; 

/*         External  Procedure  Declarations  */ 

itc$ret$vp:  procedure  byte  external;     , 
end; 

itc$loai$vp:  ?rocepupe(pri$pariv,dbr$?arro  external; 
declare  prisparm  byte, 
dbrsfarm  word; 
end; 

idlesvp:  procedure  external; 
end; 

itc^sendspreempt:  procedure(tgt$cfu  ♦  vpild  )  external; 

declare  tgtscpu  word, 
vfsid   word; 
end; 


/»•*  »**  *•*  »'*»t»  %•*  ti*  *'»  «**  *•*«'*  .'»  »*»*•*  *t«  »•-  »•,  *■**'#  »»»  .>y  »*«  »•»  »■*  *>•*•*  »»#  «'•«**  »>-  »'-  *»*  *'-  »'«  «■*  *•*  %■*  *>*  %*.  »■•  fci,  «>.  »»■  «t«  *'»  »»,  *••»**  *•.  »*»  %•»  »i»  «>*  .'*  »•*  »*.  *i«  *'.*.■-  y 
*»»  *»»  »|»  *(»»,»  *|»  *|«  »j»  »#«  *(*«|*  »4»  «(••%«  »|»  *»**!*  *•**»*  »»»  *|*  »**  *l»  *|*  »t*  *•"  *•*  ******  *»*  ***  *»*  *•*  *»*  *l*  ***  *»"*  *l*  *«*  *t*  'l**!*  *|*  *|*  *|*  -|»  **»  *t*  *«*  *(•  *»»  *l"  *»*  *»*  ***  **"  *t"   't*  1*  / 

/*  THE  PROCESS  SCHEDULER  */ 

/a-  ■*•-  o-  y«  %i*  *b  «i«  *'*  y*  *■'■•  **-  **-  «*' «■»-  *»'  <*'' **■  -'-  -''  V*  -*'  ■J-  ***  *•'  *'* *''  **'  *** *'"  *.'-  ***  *'*  ***  -1'  ***  **■*  ***  ***  *'*  •J-  •**  *''  J* *••-  »'*  *•*  *■•-  *'"  * *'-  «*•* »'-  •'«  -f-  *•-  *'-  *•-  •/*  *•'   ■ 
•"!»  »|»  *(»  *|*  *|»  »(»  *|*  *|»  *|»  *[*  *|»  ^|%  *)*  ^|»  *|»  •'i*  *|»  r|-*  *^  J|»  *|^  *i»  #p  *|*  »|*  ^^  #i*  *|»  *|»  >|»  »|*  *|»  *|»  »i»  *f»  *|»  *|»  *|»  *f*  *|-*  *|*  ff*  *-t»  <>,■*  *^>  »,-.  *,*  *t»  *(n  *(»  #p  *,*  ^|*  »,-■  »|»  •■4*  *,■*.  *(■»  *,*  / 

/••»  »•*  »•»  »'*  *»*  »■»  %*»  »'*  »*-  v*»  %»-  *»*  »'»  ••*  •*«  »**  *•«  »**  **«  «**  *•*  »'•  »'#  **#  «**  »■*  *'*  .'»  •*»  .'#  «'«  •'*  »'»  »•-  »'»  .'-  *'*  »•♦  »**  »•-  »**  »'#  *•-  *»*  »»*  »'  .  »»■  «'*  *■»  »»»  ht*  »l.  «!«.  *'-  *»j.  mj*    J„  -t.    / 
•1*  *i*  *i*  *»*  »»*  "»»  1*  ***  *»*  *|*  *»*  ***  *»*  *t*  »»*  *••  *|*  *|*  *,»  *»*  *»*  »i*  *■**  »**  *•*  *•*  *»*  *••  *4*  *»•  •"»*  *t*  *•*  *»*  *»*  *»*  *»*  **'*  ***  *,*  *!»  ».*  »**  »,*  *,»  *»•  *»»  *V  *•*  ***  ***  "  '1*  T"  *l*  ****  *i"*  *F  / 

/*     TC^SCEEDULER  Procedure  */ 

/* */ 

/*  Process  scheduler.   Searches  for  the  highest  */ 

/*  priority  runnable  process  to  load  onto  the  */ 

/*  virtual  processor.   If  no  runnahle  process  is  */ 

/*  found,  will  idle  the  virtual  processor.  */ 

TC^SCHEDUIER:  PROCEDURE  REENTRANT  PUBLIC; 
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DECLARE  PROCESS        SITE, 
SELECT$?ROCESS  2YTEJ 

PROCESS  =  LOAD$LIST(CPU$NtJMBER); 

SELECT^PROCESS  =  FALSE? 

/*  Search  down  Load^List  for  the  highest  priority  */ 

/*  ready  process  runnable  on  this  physical  processor.  */ 

DO  WHILE  /*  Have  not  found  a  runnable  process.  */ 
(SELECT^PROCESS  =  FALSE); 

IF  /*  Haven't  reached  the  end  of  the  Load^List  */ 
(PROCESS  <>  ML)  THEN 

DO;  /*  Check  process.  */ 

IF  /*  Process  is  ready.  */ 

(APT(PROCSSS). STATE  =  READT)  THEN 

/*  Select  the  process  to  run.  */ 
SELECTiFROCESS  =  TRUE; 

ELSE 

/*  Check  the  next  orocess.  */ 
PROCESS  =  APT  (PROCESS  ).LOAB$TEREAI3; 

END;  /*  If  then  else.  */ 

END;  /*  While  loop  search  for  next  ready  process.  */ 

IF  /*  Have  found  a  ready  process  to  run.  */ 
(SELECT$PROCESS  =  TRUE)  THEN 

DO;  /*  Give  away  the  virtual  processor.  */ 

APT (PROCESS) .STATE  =  RUNNING; 

APT(PROCESS ) .VP$ID  =  ITC$RET$VP; 

CALL  ITC$LOAD$VP(APT( PROCESS ). PRIORITY, APT(PROCESS ) .DBR) J 
END;  /*  Give  away  the  virtual  processor.  */ 

ELSE 

/*  No  runnable  process  has  been  found  so  idle  the     */ 
/*  virtual  processor.  */ 

call  idle^vp; 

return; 
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END;    /*   TC^SCHEDULER  Procedure.-/ 

/JU  %■*  dh  Uu  «JU  *U  «J*  *'-  J,  »t»  »'-  <*-  -•-  »*■«■  V«  »*■»  * '-»  -J-  *■'*  ***  ^,-  ***  **-  *•■*  V*  *'■»  **-  -'-  V*  »■'■*  -,*  -''  «-'-  *■'■»  ***  V'  «**  *-**  -'*  *■*-  ***  -'*■  »'*  V*  **"  - **  *J-  V'  «■'-  V'  *'-  -'-  V'  *t"  *'*  **'  **-  J-  »'#■     / 
*|*  »p  #(*   *p  *(»  *!■*  *|*  *■(*  *"p    #|*  »(*  *fc  *(**|»  J|»   *,»   *,-»   *("i  *|S  *t*  *|*  *|*  «|4>  j",*   *■,■«   »j»  #|*   #|*  ^f»   *-,»  *jfc   »,-.    ^(s  *p  *|»  *t»  »|>  »,»   *,»  *(%  *(»  »!»  *|»  #p  ^|»  *,»•  *|*  >|%   *p  ^»  *(*  »|*  *|»  »|*»  #|»  *i»  ^|*  *V»  *tf*      / 

/*  PROCESS  SCEEPULSR  INTERNAL  MODULES  */ 

/*»*  -»«.  *J~  »' -  ■»■-  •*'-  J-  *V  '■•-*  •'•*  ^T*  *■*-  *'-*  *J-  -V  *•'  -  «■* '  » '-  «■**  ■".'*  -'*  *»*  -J*  •*'-  ^-  ^'*  >u  *ju  - '.  »•-  V*  ***  **"  ***  *■*»  *■-  *■**  «-,»  -V  *•**  <^U  ^*-  »'*  -*-  **■*  ***  •* '  ***  - '-  ■•'<»  V'  *>''  - '  -  J  *  ***  • '  -  -**  ■',-  ***    / 
*n  *i*  *«*  *i*  *r*  *f  *i*  ***  "i*  *t*  t*  "i*  *i*  *»*  *n  n*  "»*  t^  t*  *i**  i*  *v  i*  i*  i"  *<*  *i*  *i'  *n  *P  *i*  **■*  i*  *v*  *»*  *i*  *»*  *r*  *fi  *i*  tP  *r*  ***  *t*  *r»  "t1*  "t*  *»*  *i*  it  v  *i*  *">*  f  **"*  *i*  'i*  *v  t*  / 

/*■'*  ^*f  ***  *'*  -'*  ^*  i*-  **■*  »'-  ^**  V'  »'-  "**  "*■*  ■**-  *f -  "'*  "' *  »' '  J-  >'*  ***  »J-  *'*  *''  »'*  **■*  *■■  *  ■*'*  »'*  *'-  •**  *■*»  ^* -  *'*  -'-  *■*'  **'  •» '*  *'*  **-  »*-  *'■*  *■'*  **-  *'*  *'*  *'*  »■-  **«  * '»  ■»*'  »' »  *' '  »p»  **-  * ' *  *'•■  »'*     / 
*|»  1*  *|*   *|*  »|»  *|»  ^*  *f»  *(»   *,»  ^*   *|*   #|»»|*   -,»   *,»  ^(*   -^»  *|*  7|%  ^5  #|V  ^(-»  »,»   »t»  »(%  *j»   »,»  »t»   *t»  *j*  »,»   *,»  *,•  *a*  #t«  *|»  *(»  »,«   *,»   *,.  *,»  *j»  n»  *!*   »,»  *^>  *,*   »(»  -,-   rt%    r%*  »4*  »(»  *,»  *t»   *,»  *,»  »4»       / 

/*     TC$LOCATE$EVC  Procedure.  */ 

/# */ 

/*  Function  call.   Returns  the  identity  of  the  */ 

/*  eventcount  (the  index  of  the  eventcount  in  the  */ 

/*  Eventcount  Tatle)  in  the  AX  (Accumulator)  */ 

/*  Register.   Input  argument  is  a  pointer  tc  the  */ 

/*  byte  array  in  the  user  process  holding  the  name  */ 

/*  of  the  eventcount.  */ 

/OU  %U  «V  U.  «JU  gu  «L.  U*  U«  «)U  VU  VU  <JU  Vt*  OU  U.  *U  JL  JU  U*  <JU  -JU  JU  JU  Op  *U  gL*  »U  **•  «.U  JU  *t.  «k>  *.!•  JU  «b  *»*  *»*  »«*  «U  JU  «C  *•*  *V  *V  **-  *!*»•*•»#  »••*'••*.  Oa  »«-  *»*  *'-  »•*  ••»  •»•     / 
*l%  ^|*  ^f»  #,^  a^fc  *^4  ^f»  ^,*  *|*  *|«  ^p  *p  *j*  i*p  *y**  *|*  *i*  1*  *|*  *i*  1*  *P  "TP  T*  *>■*  *|*  *|*  *p>*(*  *»*  "8*  *»■*  *»'*  *l*  t(*  t*  *i*  *4*  nP  ^^    I*  T*  *"<*  HP  nP  *i*  *i*  "**     '"  ^     **       *      *™  ***    •      •      *    ^      *     y 

TC$LOCATE$EVC  :  PROCEDURE (E$NAME$PTR)  BYTE  REENTRANT  PU2LICJ 

DECLARE  E$NAME$PTR  POINTER? 

DECLARE  CHAR  BASED  SiNAME$FTR  (5)  BYTE; 

DECLARE  I       BYTE, 

EVC$ID  BYTE, 

MATCH   BYTE; 

1  =  0; 
EVC$ID  =  0; 
MATCH  =  FALSE; 

/*  Search  down  the  eventcount  table  to  locate  the  */ 
/*  desired  eventcount  by  matching  the  names       */ 

DO  WEILS  /*  haven't  found  the  eventcount  and  :;:/ 
/*  haven't  reached  end  of  table     */ 
(MATCH  =  FALSE)  AND  (EVC$ID  <  EVENTS); 

IF  /*  the  two  characters  match  */ 

(CEAR(I)  =  EVC$TABLE(EVC$ID) .EVC$NAME ( I ) )  TEEN 

DO;  /*  Check  for  end  of  strings  */ 

IF  /*  Reached  the  end  of  the  strings  */ 
CHAR (I)  =  '%'  THEN 

/*  Eave    located  the  desired  eventcount  */ 
MATCH  =  TRUE; 
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ELSE 

/*  look  at  the  next  character  */ 

i  =  I  +  1; 

END;  /*  Check  for  end  of  strings  */ 
EISE 

DO;  /*  Ready  for  check  next  entry  */ 

I  =  0; 

EVC$IE  =  EVC$ID  +  i; 

END;  /*  Ready  for  check  next  entry  */ 

END?  /*  While  loop  search  for  desired  eventcount  */ 

IE  /*  Have  found  the  eventcount  */ 
(MATCH  =  TRUE)  THEN 

/*  Return  its  index  in  the  3VC$TA3LE  */ 
RETURN  EVC$IDJ 

ELSE 

/*  Return  NOT^FOUND  error  code  */ 
RETURN  NOT$FOUNDJ 

END;  /*  TCilOCATE^EVC  Procedure.  */ 

*|»  *|*  *|*  *|*  *f*  1*  *|*>  *f*  *|«  ^|^*|%  <»|»  »,*  -,»  *^  *yk  -f*  1-  -f»  *|%  rff»  »(*  *-g»  *^fc  'p  »f»  *f»  >|»  »,»  *K*  *(%  »f»  *(»  *)»*(*  «>p.  »|%  *|»  »,»  *|*  »,%  *p  »j»  *(*  r(*  »,*  -,■-  »(>  *,*«|«  *t»  *t»  *,»  »,»  «■,■.  »,«.  #,•»  *,»   / 

/*            TCsLOCATE^SEQ   Procedure  »/ 

/* */ 

/*  Function  call.   Returns  the  index  in  the  */ 

/*  sequencer  ta"ble  of  the  sequencer  name  ^iven  */ 

/*  to  it.   Input  arguament  is  a  pointer  to  the  */ 

/*  string  name  of  the  sequencer  in  the  application  */ 

/*  program.  */ 

/*'*  11*  ***  *■'■*  -V  ***•  "•'■*  *■'•*  "l*  "-1-  V'  *'•*  *•*  **?  *■'-  ***  *'•■  *J'  fct-  *'-  "■*»  ***  +*-  ***  *'*  ***  '■■'  "•'-  ***  *■'-  v'*  *•*  v*'  ***  J*  »'*  *■'*  *'-  **-  •*''  *'*  'J*  ***  fcI*  *'<*  *' '  **-  *''  **-  *'*  ** '  *'-  *■'*  *'"  -'■*  *'*  *'*  *'■  / 
mfi  *^  *|*  *|%  »g*  »|»  *,*  *,*  ^-»  rfi  *p  *|*  *)»*|»  »|%  *(*  ^p  -,v  ^,«  #,■»  #,»  *^»  #,»  *,-.  *|*  *,■»  *|»  V|««|«  *!*  *|»  .,■»  *|»  *,»  *(■•  #,*  *|»  »-f»  *■,«.  #,•  *|»  V|%  *|*  *|»  »|»  *■(»  »|»  »(»  *|»  *,»  *j*  »(»  *(*  *|»  *(*  *|-  »|*  »(»  / 

TC^LOCATEiSEC:  PROCErURE(S$NAME$PTR)  ETTE  REENTRANT  PUBLIC  J 

DECLARE  S$NAME$PTR  POINTER; 

DECLARE  CHAR  BASED  SsNAME?PTR  (5)  BYTE? 

DECLARE  I      BYTE, 

SEQSID  BYTE, 

MATCH   BITS; 
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I  =  e; 

SSO^ID  =  0J 
MATCH  =  FALSE; 

/*  Search  down  the  sequencer  taole  to  locate  the  */ 
/*  desired  sequencer  "by  matching  the  names.      */ 

DO  WHILE  /*  Haven't  found  the  sequencer  and  */ 
/*  haven't  exhausted  the  list.     */ 
(MATCH  =  FALSE)  ANT  (SEQ$ID  <  SEQUENCERS ) \ 

IF  /*  The  two  characters  match.  */ 

(CHAR(I)  =  SEQ$TABLE(SEQ$ID).SEQ$NAME(l))  THEN 

DO;  /*  Check  for  end  of  strings.  */ 

IF  /*  Reached  the  end  of  the  strings.  */ 
CHAR  (I)  =  '%'  THEN 

/*  Have  located  the  desired  sequencer.  */ 
MATCH  =  TRUE? 

ELSE 

/*  look  at  the  next  character.  */ 
I=I+i; 

END;  /*  Check  for  end  of  strings.  */ 

ELSE 

DO;  /*  Ready  for  check  of  next  entry.  */ 

I  =  0; 

SECilD  =  SEQ$IB  +  i; 

END;  /*  Ready  for  check  of  next  entry.  */ 

END;  /*  While  loop  search  for  desired  sequencer.  *./ 

IF  /*  Have  found  the  sequencer.  */ 
(MATCH  =  TRUE)  THEN 

/*  Return  its  index  in  the  SEQSTAELE.  */ 
RETURN  SEC s  ID; 

ELSE 
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/*  Return  NOT$ FOUND  error  code.  */ 
RETURN  NOT$FOUND; 

END;  /*  TC$LOCATE$SEC  Procedure.  */ 

/*t  i*;  2*;  5°  si  2k  sft  ric  ;?;  it  at  at  a!*  s**  ah  sk  *■*•  at  *l*  at  ■&  afc  at  a!*  at  ***  a*-  ***  **-  A  5**  ale  J*  *  -J1*  **-  «*»  **» -*»  ***  **-  ***  ***  **•  *  *"*  *  **>  *■*  »'*  *■-  *•*  -ju  *i*  *»*  «j*  »•»  a*   / 
-,»  *,»  <-,*.  -,-  -,»  -,»  -■,*  #|%  *|»  ^  *-i*  *^  *|*  -,»  -,»  -,»  »(s  .-,»  ^,«.  or-  *i*  *n  HT  "P  T*  *»*  *F  1*  *<*  *l*  *t*  *l*>  ***  *i*  t*  1*  'i*  *^  *l*  *i*  *)*  1*  *l*  ****  T"  *i*  *5*  n*  "i*  *i*  *»*  ■§■  ***  *T*  *V*  *»*  *¥*  *tf*    / 

/*  TRAFFIC  CONTROLLER  INTERFACE  MODULES  */ 

/**"  »**•*•  .»-»•-  «■•«**  »'*  »'»  «*••!*  «.**  *■»»•»  »'-  »•*  •#«  ******  ***  *»*  *'*»•*  »»*  *•**'*  *«»  ••*«'«  »*»  *•*  *.'*  *.'*  »»-  «L*  *•-  ******  *'•  »V  •**  *•*  »•*  »•»  *•*  ***  ******  %**  »**  *•-  *•*  *»*  •»*  »'*  »**  *•*  %**   / 
*,*  *»*  *(*  »(■»  *t»  *(*  *|*  *»»  »(*  *,»*'|»  »,*  »,*•"(*  «,«■  #,»  *f»  *|*  *(»  »^»  *|»  *J*  »|»  *,-  *,*  rf%    r%-.    >>,«  f(*  »(»  *,*  -,•  *,»  »,»  *|«  *,*  *|*  »|»  *(»  *j*  *|*  *(«  *,»  .,.  *,*  *,*  rt  .  *,*  *j*  *j*  »,*  *,•  *,*  *(*  *,*  *,»  »,-.  *(»   / 

/  jl.  ^ **-  *<-  **-*•-  ji*  xi_  »»-  *vu*  a*  «b *f*  a*  jl v- *** u- *ju •», a*  ju **-  «k u* *t* %u *>*  a« *v  V-  V- »*- *^- a-  *»- u*  *i* *t* o* *•*%»#•*•  **•  a*****1*  o**v%**  >'-*»-*•-*»-*■-*«-  *ju  / 

/  *i*  *i»  *1*  *|*  *|*  *l*  *|*  *|»  *|*  *^*|*  *(*  -,*«,«  *p  *|%  *,«.  *|**|»  *|*  *|*  *f*  *,»  -,*  *|^  --,»  *,*  "i»  -,-»  -,*  -,>  ^^  3(»  *|»  *^»  ^|*  ,,*  *y*  ^»  »,*  *|*  *)»  ?,5  *|*  -j*  #(*  J|»  *,<•  *(»*|»  "i*  *i*  *i»  *|*  *^*  *p  *|*  *i*  / 

/*     AWAIT  Procedure  */ 

/* */ 

/*  Inter-process  synchronization  primitive.  */ 

/*  Suspends  execution  of  the  calling  process  until  */ 

/*  the  event  specified  in  the  input  argument  */ 

/*  'EYC$7AL£PARM'  has  occurred  (the  eventcount  */ 

/*  reaches  this  value).   The  result  is  that  the  */ 

/*  process  will  "^ive  away"  the  virtual  processor  */ 

/*  to  which  it  is  hound.  */ 

/•Jr  *IU  *l«  *.'-  -*-  -A*  *l*  -.'-■  »*-■  tJLr  a*  **••  a*  -Jjf  «i*  0*  >.C  ***  OU  *l*  *JU  *l*  *l*  ***  ■»•-  *<*  *•»  %**■  *■«  *l*  -'-  **»  *I*  «l*  »JU  *•-•  «J*  *•■'  -'-  *(*  -'-  *t*  *l*  »i»  *4*  *!•  ***  «>-  >J*  *f*  «.*»  »'.  **«  -J»  -."*  -.'-  *JU  «'*   / 
^t  *|*  *|*>  *(*  *J*  *|»  *|*  *|«»  *^  *■(*  *J*  *|*  »,«  -,*  *|*  *f»   *|*  *|*>  »,-»  *|*  *|*  *|»  *|»  »|»  *,»»■,«  *f*  -,»  »,»  *p  -,-»  ,>,-.  *(*  »(»  ^,»  *,»  »,-.  *,-.  *|«  *,*  *j*  «f*  *|*  *t»  *|*  *(>  y,.  »,»  *-,-  ^(»  ^,»  *(»  *#*  *|*  *t»  *(*  *,*  »(*   / 

AWAIT:  PROCEDURE (EVENTCOUNT, VALUE)  REENTRANT  PUBLIC? 

DECLARE     EVENTCOUNT  POINTER, 

VAIUE  WORD, 

EVC$ID  BITE, 

CURRENTS?  LITE, 

PROCESS  byte; 

/*  Assert  slohal  Iock  on  the  Active  Process  Tahle.  */ 

do  while  l0ckset(gapt$lcce,119); 
end; 

/*  G-et  identity  of  the  virtual  processor  running  on     */ 
/*  physical  processor.  */ 

CURRENT$VP  =  ITC$RET$V?; 

/*  Search  the  Active  Process  Taole  ("by  the  load  List  */ 

/*  to  find  the  process  hound  to  the  running  virtual  * / 

/*  processor.  */ 

PROCESS  =  LOADSLIST(CPU^NUMBER); 

DO  WHILE  /*  Haven't  found  the  process  tound  to  this  vp.  */ 
(APT(PROCESS).VPilD  <>  CURRENT^VP  ) ; 

/*  Look  at  the  next  entry  in  the  load^List.  */ 
PROCESS  =  APT (PROCESS ) .L0AD$THREAD; 
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END;  /*  While  loop  search  of  LoadsList.  */ 

/*  Get  the  EVC$TA£LE  index  for  this  eventcount.  */ 
EVC$ID  -  TC$LOCATE$EVC(EVE.\'TCOUNT)  J 

IE  /*  This  process  is  to  enter  the  blocked  state.  */ 
EVC$TAEL5(EVC$IL).EVC$VALUE  <  VAIUS  THEN 

DO;  /*  Set  the  required  APT  values.  */ 

APT (PROCESS ). STATE  =  P.LCCKED? 

APT(PROCESS).VP$ID  =  Nil; 

AFT (PROCESS ) .EVCSVALUE^AW  =  VALUE; 

/*  Add  blocked  process  to  head  of  blocked  list.  */ 
APT(FROCESS). THREAD  =   EVC$TABLE (SVC ?ID ) . AFTSFTR ; 

/*  Reset  table  pointer  to  the  current  process.  */ 
EVCsTABLE(SVC$ID).APT$PTR  =  CURRENTSVPJ 

END;  /*  Do.   Place  process  in  the  blocked  state.  */ 

ELSE 

/*  If  the  event  has  already  occurred,  process  will   */ 
/*  enter  the  ready  state  —  it  will  not  be  blocked.  */ 
APT(PROCESS). STATE  =  READY j 
APT(PROCESS).VP$ID  =  NIL,* 

CALL  TC$SCHErULER; 

/*  Unlock  global  Active  Process  Table  Lock.  */ 

apt$lock  =  e; 
return; 

END;  /*  AWAIT  Procedure.  */ 

/»*„  .1,  o,  j»  a*  v'*  «M  -*-  *>'  «'«  -*'  -'-  y*  *.»*  ■**-  »'*  V-  ***  y*  *•-  "*'  *■'"  •*'  y-  »'-  V'  *'-  *'*  *•*  ■*•-  »''  ■»'*  -'-  -*-  -1-  »•-  "'-  «•''  *'*  -''  »•-  -'-  «••'  y -  »*-  -'-  -' •  »'-  »  '*  «Jt#  **  -J-  *»*  *»-  «'-  JU  »**  db  / 
^|*  *^  »(*  ^4*  *|»  *|S  +f*   »i»  *f*  r(»  »|»  «|%  rf|%  *|»  T*  *|»  <■,>  -f*  #,*  «^»  »i*  •(»  »,»  ^»  *|*  J,-  *j»  »|»  *|»  »|*  W|»  *,»  *|»  »|»  ^*  *|»  *j»  *[*  »,»  r(»  *\-+  wf%   *|*  *f»  *,<•  «-j»  »,»  *(»  »t*  r,»  *,»  *,*  *|»  *(»  »t%  *,*  *,s  *,»   / 

/*     ADVANCE  Procedure  */ 

/* */ 

/*  Used  to  signal  the  occurrence  of  a  specified  */ 

/:::  event.   Increments  the  current  value  of  the  */ 

/*  eventcount.   Also  signals  all  processes  which  */ 

/*  are  in  the  blocked  state  waiting  for  this  event.  */ 

/«i«  *<*  y«  *•*  y*  y*  *•*  y*  y-*  y*  *u>  j*  *ju  *ju  .ju  v*  *t*  y*  •**  ***  ***  y»  ***  y*  sfe  ***  ***  ***  ***  y?  ***  ***  y*  ***  ***  *•*  ***  **•  *'*  y*  y-  y<*  ***  y^  ***  ■**  y*  **<•  y*  ***  y*  **»  ***  ***  *^  y*  ***  ***  / 
^»  •^t  Jf*  *,«  -,-»  Jj»  *,*  *-|»  *,*  #,»»,»  «yk  *(*"  "I"  ^*  *,»  *^*  *|**l*  *!**  1*  rC   '<*  *!'*  *"l*  *l*  *l*  *l**l*  *l*  *l*  ^1*  *t%   '!**«*  *»*  *l**  1*  *l*  *4*  *l*  'I*  *!**»*  *1*  V  *t*  *i*  *.*  *T*  *t*  *l*  *t"   *l*  "k"   *l"  *l*  *i*  / 
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ADVANCE:  PROCEDURE (EVENTCOUNT)  REENTRANT  FUELICJ 


DECLARE 

EVENTCOUNT 

POINTER, 

EVC^ID 

BYTE, 

PROCESS 

BYTE, 

PREV 

BYTE, 

PEP 

BYT?, 

VP 

BYTE, 

HI$PRI 

BYTE, 

PE$TO$SEND 

BYTE, 

PE^SENT 

byte; 

DECLARE 

PESPHP(16) 

BYTE, 

PESVP(4) 

BYTE; 

global 

lock  on  the 

Active  Process 

Table.  */ 

do  weile  l0ciset((?apt$l0ck,119); 
end; 

/*  Increment  the  value  of  the  eventcount  by  one.  */ 
EVC$TABLE(EVC$ID).EVC$VALUE  = 
EVC$TABLE(EVC$ID).EVC$VAIUE  +  U 

/*  Search  Blocked  List  associated  with  the  eventcount  */ 

/*   and  unblock  those  processes  waiting  for  this       */ 

/*  event.   Set  PROCESS  to  the  first  member  of  the     */ 

/*  Blocked  List .  */ 
PROCESS  =  EVCiTABLE(EVC*ID).AFT$FTR; 

PPEV  ■  process; 

/*  Initialize  PE$PHF  array.  */ 
DO  PHP  =  0  TO  NRiPFPSJ 

?e$phf(ffp)  =  fals*; 
end; 

DO  WHILE  /*  Not  end  of  Blocked  List.  */ 

process  <>  nil; 

IF  /*  The  event  has  already  occured.  :;:/ 
(EVC$TAELE(EVC$ID).EVC$VALUE  >= 
APT  (PROCESS  ).EVC$VALUE$AW)  THEN 

DO;  /*  Unblock  process  (set  state  to  ready ),    zero   */ 
/*  Eventcount  Value  Awaited  entry  of  APT  and    */ 
/*  flag  the  physical  processor  for  preemption.   */ 
APT(PROCESS). STATE  =  READY; 
APT  (PROCESS ).EVC$  VALUE  $  HW  =  0  ; 
FE$PEF(AFT (PROCESS). AFFINITY)  =  TRUE; 
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/*  Remove  process  from  the  Blocked  List.  */ 

IF  /*  First  member  of  the  Blocked  list.   */ 
(PREV  =  NIL)  THEN 

/*  RoSet  pointer  around  the  deleted  mem  "her.  */ 
EVC$TABLE(EVC$ID).APT$FTR  = 
APT (PROCESS). thread; 

ELSE 

/*  Set  previous  member's  pointer  around  the  */ 
/*  deleted  process.  */ 

APT (PREV). THREAD  =  APT( PROCESS ) .THREAD 

END;  /*  Do.   Remove  process  from  Slocked  List.  */ 

/*  SEARCH  NEXT  ENTRY  */ 

PREV  =  PROCESS? 

PROCESS  =  APT(PROCESS). THREAD; 

END;  /*  While  loop  search  of  Blocked  List.  */ 

DO  /*  Look  for  the  PHP's  with  VP's  to  Dreempt.  */ 

php  =  0  to  pfps; 

IF  /*  PHP  is  flagged  for  a  preempt.  */ 
?E$?F?(PHP)  =  TRUE  THEN 

DO;  /*  Find  VP's  to  preempt.  */ 

DO  /*  Flag  all  VP's  for  preemption.  */ 

vp  =  e  to  7ps$fer$cpu; 

pe$v?(vp)  =  true; 

END;  /*  Initialize  PE$VP  array.  */ 

hi£pri=  e; 

PE$T0$SENP  =  0; 

PROCESS  =  load$list(fhp); 

DO  WHILE  /*  Search  down  Load  List  to  find  those  */ 
/*  processes  which  should  he  running.  */ 
/*  Determine  v»hich  VPs  not  to  preemot.   */ 

(PROCESS  <>  NIL)  A.ND 

(KI$P?.I  <  VFS$PER$CFU); 
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IF  /*  Found  a  process  which  should  be  running  */ 
/*  that  actually  is  running.        */ 

APT(PROCESS). STATE  =  RUNNING  TFSN 

DO;  /*  Increment  number  found  and  do  not  */ 
/*  preempt  its  VP.  */ 

HI$PRI  =  EI$PRI  +  i; 
FEi??(APT(?ROCESS)  .V?!?ID)  =  FALSE; 

end; 

ELSE 

IF  /*  Found  a  process  which  should  le  running  */ 
/*  "but  is  in  the  ready  state.  */ 

APT (PRO CESS). STATE  =  REACT  THEN 


DO;  /*  Increment  number  found  and  indicate  */ 
/*  that  a  preempt  will  have  to  be  sent  */ 
/*  to  get  it  running.  */ 

EI^PRI  =  HI$PRI  +  i; 
PE$T0$SEND  =  PE$TO$SEND  +  i; 

end; 

END;  /*  While  loop  search  of  Load  List.  */ 

PE$SENT  =  0?  /*  Used  to  seep  track  of  the  */ 

/*  number  of  oreempts  sent. 
VP  =  2i    /*  Eegin  at  first  VP  on  the  PEP.  */ 

DO  WHILE  /*  There  are  more  oreempts  to  send.  */ 
(?E$SENT  <=  PE$TO$SEND)" 

IF  /*  A  preempt  is  to  be  sent  to  this  VP.  */ 
PE$VP(VP)  =  TRUE  TEEN 

DO;  /*  Issue  the  preempt  and  tally  it.  */ 

CALL  ITC$SEND$PREEMPT(PEP,VP) f 

PE$SENT  =  PE^SENT  +  1J 

END;  /*  Issue  preempt.  */ 

/*  Check  the  next  VP .  */ 
VP  =  VP  +  1; 
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END;  /*  While  loop  send  preempts.  */ 
END;  /*  While  loop  determine  VPs  to  preempt.  */ 
END;  /*  Determine  PHPs  to  preempt.  */ 

end; 

/*  Ready  the  calling  process.  */ 
/*  Get  identity  of  running  VP.  */ 

VP  =  itc$ret$vp; 

/*  Search  Load  List  Thread  to  find  VPsiD  match.  */ 
PROCESS  =  L0AD$LIST(CPU$NTJMBER); 

DO  WHILE  /*  Have  not  found  process  hound  to  this  VP.  */ 
(A?T(PROCESS).VP!?ID  <>  VP  )  J 

/*  Look  at  next  entry  in  Load  List.  */ 
PROCESS  =  apt(process).load$teread; 

END;  /*  While  loop  search  of  Load  List.  */ 

/*  Ready  the  calling  process.  */ 
APT( PROCESS). STATE  =  READY? 
APT(PROCESS).VP$ID  =  NIL? 

CALL  tc^scfedulsr; 


/*  Unlock  Active  Process  Table.  */ 
AFT$L0CK  =  0J 

return; 

END;  /*  ADVANCE  procedure.  */ 

/°-  akafe  **-  *■*»  "'-  =^  -J- -J-  Vr-J-  **-  5*»*Jfc  n»-  *'-  *v  -'-o->  .j,  .ju  y^  ***  ***  *>r  -*-  -J'  «ju<i>-  •>»-> *k  j-  a,  JL **•  *»«■ a*  >*-  *•-  %»«•  j,jw-vW*  *** *»-.«.'*  *•*<.>..  -jl.  «i>  *•-*,•.  0..  .j-  •.»*  *h  / 
/  *j*  *|*  *ffr  +^  *(%  *,»  *i»  -1%  *|*  .v*  *,-*  *,»  ^[*  *^»  -^  »,<*  *,s  <y*  *i*  ■t*  "|5  t*  *¥*  t*  hp  tp  *i*  *i*  nr*  *»*  i*  *i*  *%•  i*  i*  *i*  t*  t*  i*  *i*  *>*  *r*  *»*  *■**  t*  *i*  *i*  ***  'i*  1*  *i*  *i*  *i*  *i*  •**  *t*  i*  *r*  / 

/*     TICKET  Procedure  */ 

*f*   »WW*f  —  ««WM  —  w-i.il        —  — —         I     ■■    ■!  I        I   Ml  —  W  M   —  IIIM   ■■■   ■■   —   «  Ml      ■    »  —   ■■   —————  —  •'(-/ 

/*     Function  call.   Returns  a  unique  sequencer  value.   */ 

/%•*  ***  »'*  **»  ***  %'*  *'-  ••*  *'•  »'*»'-  «*■>  ■*'*«.•-  *»»  »•*  «L.  •'-  «,'*  »»»  «.'*  %'••!«  %'.  fc».  •  ■*  »'-  <.'**•*  %•«  »■*  **«  «*«  »«.  *>•  «J«  %•*  »'#  »'-  »•*  «•#  »•*  ******  »'*  »»-  «••  *l*  *'-»•»  .'.  *•»  %».  «'**'*  *•*  *.'-  »•*   / 
«■»*  ^»  •)(•  *(■«  •J*  »4»  *j»  »(»  >|*  *,*  »j*  »,»  *|»  #t*  *|»  »|»  *,%  #|*  -,-  »,»  »4»  »|»  »,»  »^  »|*  »|<*  *t»  »|'»  *,»  »,»  #»*  »4»  »|«  *,»  *4%  #,>  r(*  »|*  »,•  *,*  -,%  #,»  *,»  *,*  »#»  *,»  »,»  *,»  »»»  *|*  *(«  »,»  »,«  »|»  »(»  -4»  »,»  »(»   / 

TICKET:  PROCEDURE (S HO UENCER)  BYTE  REENTRANT  PUPLICJ 
DECLARE  SEQUENCER  POINTER, 
SEQ^ID     EYTE, 
VALUE     word; 
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/*  lock  the  Active  Process  Table.  */ 

do  while  l0cxset((?apt$l0ck,119)i 
end; 

/*  Identify  the  sequencer.  */ 
SEQ$ID  =  LOCATESSEQ(SEQUENCER); 

/*  First  obtain  value  to  he  returned  to  the  caller  */ 
VALUE  =  SEQ$TABLE(5EQ$ID) .SEO$VALUEJ 

/*   Then    increment    the   value    of    the   sequencer  */ 
SEQ$TA3LE(SEQ$ID).SEQ$VALTJE    = 
SEQ$TABLE(SEQ$ID).SEQ$VALUE    +   l; 

/*  Unlock   the  Active   Process    Table   */ 

apt$lock  =  0; 

/*  Return  the  value  to  the  caller.  */ 
RETURN  VALUE; 
END;  /*  TICKET  Procedure.  */ 

/»•*  *'•  ***  *•#  »' *  »'«  •■ '»  »**  «'«  *JU  *' •  ■  *»  »'»  »'«  *' »  »'*  » ' •  »'  -  »'*  *' »  »U»  ■.'#  »<»  *' »  *■  *  »'*  » ■>  *■,,  *•«  »' ,  fc*.  *t*  ,'*  »■*  »'*  »*»  %l«  «l«  » ■ ,  »>.  ^1»  »L,  V*  *JU  «,'*  «.t»  -J*  «.  *-  »',.  -JU  »-'*  «,'^  fci-  *J-*  "■'*  "J-"  V-*  ***   / 
»,*  *<*  *|»  »|»  *|«  *^»  »|»  *l»  •(*  »!"*!»  *»»  *l**l*  *»*  ******  ^**t*  »(•  *»**!*  *l*  *l*  *l*^*  *•*  *!**»*  *»*  *•*  *|*  *i*  *l**"i*  *|*  *»**»*  *•»  *»*  *l*  ^*  ^H"4*  TT  1*  *■(*  "»*  *t*  *|*  *»"»  1*  *l*  'I*  'I*  •***  *l*  1*  / 

/*     READ  Procedure  */ 

/* */ 

/*     Function  call.   Peturns  the  current  value  of  the   */ 
/*     eventcount  specified  in  the  call.  */ 

/*!*>  *J*  »1U  »V  «A«  ***  %!•>  V-  ■»**  k"j  »'»  *t*  <JL><JL*  »C  fci>  »t*  V<*  »•*  •*»  »*»  »'*»!*  J#  J-  »'»  »•*  »•»  »**  »**  »•»  i'»  •'*  »f-  %**  »•*  **»»'*  *'*  »'•  »'*  ***  %'*••*  »'*  »*•  ***  »'#  **-  ***  »**  »»-  »'-  %**  »'-  ***  »'*  V*     / 
',%  t*  *"l*  'I*  *(*  "S%  'i*1  *T*  1*   T*  ■***  *1*  'l*1*!*  'J*  T*  *t*  *l*  *i*  '(*  *t*  '"I'*  "i-*  'I*  "t*  *l%  *l*  *l     *•*■  *•*  "1*   *»*  "'*   "»*  "1*      t1*  *i"  *i*  '*     *•*  *»*  *t*  "1*  *is  *•"  *«*  *i*  "i*   '»*  *1*  *i*   rtm  "("*■  "i1"  "l%  * -*   '1*  'i*     / 

READ:  PROCEDURE (EVENTCOUNT)  BYTE  REENTRANT  PU3LIC; 
DECLARE  EVENTCOUNT  POINTER, 
EVC$ID      BYTE, 
VALUE       WORD; 

/*  Lock  the  Active  Process  Table.  */ 
DO  WHILE  L0CKSET((?APT$L0CK,119); 

end;  ' 

/*  Identify  the  eventcount.  */ 
EVC$ID  =  LOCATE$EVC(EVENTCOUNT); 

/*  "Read"  the  current  value  of  the  eventcount.  */ 
VALUE  =  EVC$TA£LE(EVC$ID).EVC$VALUE; 

/*  Unlock  the  Active  Process  Table.  */ 
APT:?  LOCK  =  0; 

/*  Return  the  current  value  to  the  caller.  */ 
RETURN  VALUE,' 
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END;  /*  READ  Procedure.  */ 

/*     CREATE$EVC  Procedure  */ 

/* _ _ */ 

/*  'Creates  an  eventcount  by  making  an  entry  for  it  */ 
/*  in  the  eventcount  table  "EVC^TABLE"  and  setting  */ 
/*     the  initial  value  of  the  eventcount  to  0.  */ 

CREATE^EVC:  FROCEDURE(SVENTCGUNT )  REENTRANT  PUBLIC; 
DECLARE  EVENTCOUNT  POINTER,* 
DECLARE  CHAR  BASED  NAME  (6)  BYTE; 
DECLARE  I  BYTE; 

/*  Lock  the  A.ctive  Process  Table  */ 

do  while  l0ckset(gapt$l0ck,119); 
end; 

IE  /*  The  eventcount  had  not  already  "been  created  */ 

locate^evc (eventcount)  =  not^found  then 

do; 
I  =  0; 

DO  /*  Copy  the  name  into  EVC$TABLE  */ 
WHILE  (CHAR(I)  <>  '%')  AND  (I  <  5); 

/*  Copy  the  character  into  the  table.  */ 

EVC$TA3LE(EVENTS).EVC$NAMS(I)  =  CHAR(I); 

END;  /*  While  loop.  */ 

/*  Insert  the  delimiter  '%'  in  the  table  entry.  ♦/ 


EVC$TABLE(EVENTS).EVC$NAME(l)  = 


'0/ ' 

/o   1 


/*  Increment  EVENTS  to  indicate  a  new  addition.  */ 
EVENTS  =  EVENTS  +  1J 

END;  /*  Create  the  eventcount.  */ 

/*  Unlock  the  Active  Process  Table.  */ 
APT^LOCK  =  e; 

return; 

END;  /*  CREATE^SVC  Procedure.  »/ 

/,»,  ~.y.  a-  <j-  -'-  Jb  J*  **-  -'-  •>"-  *J?  *•*  *»*V-  *V  *'-»•'-  ->-  *>t  *''  ^  J*  *',•  -'-  v*o-  „»*  -j.o.,  *'-.',  *•-  o-  *.•«*!..  *.<-  o*<J«  -'.  *«.  »»*  »i,  u«  «i«  ***  «*#  <a»  »**  y-  «.•-  *»-  »»*  %»*  »••  o-  *••*  *'*  *'*  / 
~Y*  *|%  *(•  #f»  *|»  «y»  *|»  *(%  J|%  *ft  *,t  »(•  -r*  T*  "f*  *|*  *<■  *l*  ***  1*  ■§■  O^  *1*  T(*  "I*  ***  1*  *i*  *1*  *r*  1*  *l*  *l*  ****  1*  *1*  *t*  'I*  *!*  *<*  "t*  *l*  *|*  rt"   *l*  *t*  *t*  1*  'I*  *I*  *•*  *t*  *»*  *C  *t*  *»*  *t%  *»"*  / 

/*  CREATS^SEQ    Procedure  »/ 
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/* */ 

/*  "Creates"  a  sequencer  by  establishing  an  entry  in  */ 
/*  the  sequencer  table  "SEQ$TABLE"  and  sets  the  */ 
/*     initial  value  to  0.  */ 

1*  *i*  "v*  nr*  t*  B|*  t*  *i*  *t*  *i*  n*  ^%  ^n  ^*  *i*  1*  ^n  "**  *i^  t*  *"P  *^  I*  ***  *<*  *T"  *i*  *i*  *i*  t*  *<*  i"  n*  *i*  *•*  *i*  *i*  *r*  1*  *»*  *tf*  "f*  *•*  *i*  "i^  *p  n*  *t*  *i*  ***  *»*  *v*  *i*  *i*  "in  *i^  *■!*  *i*  / 

CPEATESSEQ:  PROCEDURE (SEQUENCER)  REENTRANT  PUBLIC; 
DECLARE  SEQUENCER  POINTER; 
DECLARE  CFAR  BASED  NAME  (6)  BYTE? 
DECLARE  I  BYTE; 

/*  Lock  the  Active  Process  Table  */ 

do  while  l0ceset(gapt$l0ck,119); 
end; 

II  /*  The  sequencer  had  not  already  been  created  */ 

locatesseq(sequencer)  =  not$found  then 
do; 

I  =  0? 

DO  /*  Copy  the  name  into  SEQSTABLE  */ 
WHILE  (CHAR(I)  <>  '%')    AND  (I  <  5)» 

/*  Copy  the  character  into  the  table.  */ 
SECSTABLE(SEQUENCERS).SSCSNAME(I)  =  CHAR(I); 

END;  /*  While  loop.  */ 

/*  Insert  the  delimiter  '%'  in  the  table  entry.  */ 
SEQ$TABIE(SEQUENCERS).SEO$NAME(I)  =  '%'; 

/*  Increment  SEQUENCERS  to  indicate  a  new  addition.  */ 
SEQUENCERS  =  SEQUENCERS  +  1J 

END;  /*  Create  the  sequencer.  */ 

/*  Unlock  the  Active  Process  Table.  */ 

aptslock  =  0j 
return; 

END;  /*  CREATE$SEQ  Procedure.  */ 

/••*  *»-»»*  .'.j,  ^  x  x  j-  j,  j.  .<*  ,!„•,  j,  ,i,  x  ,u  j,  o,  ti>  vu  a*  j,  o,  j,  j<  x  x  Op  v-  u-»  <x*  Jr  4*  ***  «**  •*•  ,J-  4-  ab  ***  ***  4t  **»  *•*  5**  •J'  **-«■**•**»  *»*"••-*  *'*  <■'»  -'*  y*  >•*    / 
*,»  *i*  »»*  *i*  *i»  -v"  *>|*  *p  *j>  •i*  *y*  ***  *»■*  "i*  *S*  *»*  ■§■  *f*  *i*  '**  *f*  *i*  *¥*  *»*  *i*  *i*  n*  't*  n*  "X*  n*  *v*  ^*  T*  *t*  r(*  *i*  i*  *i*  A*  "i*  *i*  *»*  *n  *i*  t  *>*  ***    i   "»*  *i*  *»*  *>*  *^  *i*    •*    '     »*  / 

/*     CRSATE$PROCESS  Procedure  */ 

/# . _ */ 

/*  Creates  a  process  by  initializing  its  stack  and  */ 
/*  initializing  an  entry  for  it  in  the  Active  Process  */ 
/*     Table.  */ 
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;  ^  J.  »i,  a  V#  J,  ;X  »',  a  »'*  Jt  V*  '•'  *•*  v'*  *'*  V'  '''  *'•  *•'  *•'  *'«  *U  »''  ^'  »''  *!*  V'  »'•  »'-  »'»  *••  *'*  U#  ^  «i.  J*  »i/  ,i,  *',  ,i,  J,  J.  j.  J«  o»  *i.  j,  J.  A  ii.  4,  a.  »'.  J.  y*  %tf  .J-     / 
/  rgt  *V*  *i%  ^|*  rfgfc  *|*  *|*  *|%  *|*  »,»  #■,*  j,»  •v-t*  *(*  ^*^^  *lf**l"  1*  ***  *<*  *(*  *^  *l*  *l*  *IT  *l*1*  *I*  *f*  *»*  ^^  *i*  ***  *»*  *1*  *^  1*  *i"*  *|*  *|»  *i*  *i%  *#*  *i*^*  *i*  *V  *i*  *P  *i*  *l*  *i*  *i*  't*  *i*  *p    / 


CREATE$PROCESS: 

PROCEDURE (PPB$FTR)  REENTRANT  PUBLIC; 

DECLARE  PPB$PTR  POINTER; 

DECLARE  INIT^STACKsFRAME  STRUCTURE 

(FL 

WORD, 

CS 

WORD, 

IP 

WORD, 

ES 

WORD, 

DS 

WORD, 

AX 

WORD, 

cx 

WORD, 

rx 

WORD  , 

BX 

WORD, 

SI 

W  ORD  , 

EI 

WORD, 

RET 

WORD  , 

BP 

W  ORD  , 

SP 

WORD) ; 

DECLARE  INTERRUPT  LITERALLY  '119'; 


/*  Lock  the  Active  Process  Table 

do  while  l0ckset(qaptil0ck,119); 
end; 


*/ 


/*  Set  up  initialization  stack  frame. 

INIT$STACX$FRAME.FL  =  FRO$PARAM.FL; 

INIT$STACK$JRAME.CS  =  PRCiPARAM.CS 

INIT$STACK$FRAME.IP  =  PROiPARAM.IP 

INIT$STAC£$FRAKE.ES  =  PRO^PARAM.ES 

INIT$STACK$FRAME.DS  =  PRO$PARAM.DS 

INIT^STACKiFRAME.AX  =  FRO^PARAM.AX 

INIT$STACK$FRAME.CX  =  PRO$PAEAM.CX 

INIT$STACK$FRAME.DX  =  PRO$PARAM.DX 

INIT$STACE$FRAME.BX  =  PROiPARAM.BX 

INIT^STACKSFPA^E.SI  =  PRO$PARAM.SI 

INIT$STACKiFRAME.DI  =  PRO$PARAM .DI| 
INIT^STACK^FRAME.RET  =  INTERRUPT; 

INIT$STACK$FRAME.BP  =  ej 

IMIT?STACK$FRAME.SP  =  6; 

/*  Move  initialization  stack  frame  into  memory 
M0VB(PIiMIT$STACK$FFA!*E,P?B.DBR,2e); 


/*  Enter  process  in  Active  Process  Table. 
APT(PROCESSSS). STATE  =  PPB. STATE; 
APT(PROCESSSS ). AFFINITY  =  PPB. AFFINITY; 


■■/ 
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APT(PROCESSES ).VP$IT  =  NIL; 
APT(PROCESSES ). PRIORITY  =  PPB  .PRIORITY; 
APT ( PROCESS ES).EVC$VA1UE$AW  =  0; 
APT (PROCESSES). THREAD  =  NIL; 
AFT(FROCESSES ).DBR  =  PFB.DBRJ 

/*  Enter  process  in  the  Loaded  List  by  priority  */ 
PREV  =  nil; 

NEXT  =  LOAD$LlST(CFU$NUMBER); 
DO  WHILE  PPB. PRIORITY  >  APT( NEXT ) .PRIORITY; 
PRSV  =  next; 

next  =  apt(next).load$teread; 
end; 

i?  next  =  nil  then 
a?t(?rev).loab£teread  =  entry; 

ELSE 

if  next  =  load$list(cpu$number)  teen 
do; 
a?t(entry).loal$thread  = 
load$list(cpu?number); 
load$list(cpu$number)  =  entry; 

ELSE 

do; 

apt ( pr ev ). lo ad  $ thread  =  entry; 

aft(entrt).load$teread  =  next; 
end; 

/*  Unlock    the    A.ctive   Process   Table.    */ 

apt$iock  =  e; 
return; 

END;  /*  CPEATE^PROCESS  Procedure.  */ 

/*     TC$PE$FANBLER  Procedure  */ 

/*  Fandles  preempt  interrupts.   Called  "by  the  */ 

/*  Traffic  Controller  in  response  to  a  virtual  */ 

/*  preempt  interrupt.   This  module  serves  as  the  */ 

/*  virtual  interrupt  entry  point  into  the  Traffic  */ 

/*  Controller.  */ 

/*        =========>  Constitutes  a  loop.  <===-===-=  */ 

/vv  -'-  vu  *■'<■  ■*■-  *V  *.»*  o*  v*  *'--'-  J-  -J-  -»-  >J-  <J*  .ju  -*-  J.y.a.x«uv  sfe  *'*  •**  **<•  -**  *•*  -'-  *V  ■»••»  *■*  •&  **-  <■*-  •**  *'*  *'*  *'-•  *»*  **-  ***  ***  -'•*  *V  °-  <kf*  V*  **-  *"-  A  J*  afe  tfe  V'  A    / 
*•*  *i*  *n  *"r»  *»*  *p  *y*  n**^  *i**^  *<*  ^t****  *i*  1*^1*  *<**i*  o*  ^*  *<*  *^  *•*  *P*i"*  **i*  *i**i*  *»■*  i*  "i*  *v*  *r*  *p  '»■*  *t*  *i*  *i*  *i*  ***  *i*  *«*  *>*  *t*  *»■*  *<*•  *<**  *i*  ^*  '»*  '»*  '*    *»*  *"i     ■     t*  '»*  / 

TC$PE$HANBLER:  PROCEDURE  REENTRANT  PUBLIC,* 

/*  Lock  the  Active  Process  Table.  */ 
DO  WHILE  L0CKSET(C'A?T$I0CK,119); 
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end; 
call  tc$scfeduier; 

/*   Unlock  the  Active  Process  Table.  */ 

aft$lock  =  e; 
return; 

END;  /*  TC$PE$EANDLEP.  Procedure.  */ 
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